app works for root anywhere, for users only on xfce????

English Applications
1

Hi all.

I’m having a hard time here with an application we use in the lab: MGLTools, which includes AutoDock Tools.

Downloads — MGLTools

I’ve installed it available for all users, made a fast test as root, and it was running. Then, users called my attention for the fact that it didn’t worked.

Then I tested as user, not working. Retested it as root, perfection.

Since I had to travel, I asked the users of this program to do some testing or try to find info in the web in the meantime. I was even thinking that there was something within the scripts which resulted in just one user being able to run it.

I came back from travel today, to now that the users made an astonishing discovery: It doesn’t work for them on either KDE not gnome. But when they tried fwm, it worked almost flawless! Then I suggested trying XFCE, and tehn it work as perfect as one can ask for!

Does anybody has any idea on this? Why would any program in the world, with 755 permissions for everything in it, work on KDE and Gnome only for root? And more strange, for anyone in XFCE??

Thanks in advance for any clue on this one. :slight_smile:

Edit: One extra piece of information: if an user tries to run it on either KDE or Gnome, he is imediatelly loged out of the interface. Something breaks down kdm, kdeinit, and it alikes from gnome. :stuck_out_tongue:

2

this MGLTools appears to be a GUI program…you say after you
installed it you fast tested it as root…how did you do that, and why?

what i’m asking is did you log into Gnome/KDE etc as root to install
MGLTools…or did you do that as a regular user and then used a
terminal to launch it as root…

tell you what i think you installed it while logged into the
server’s GUI as root, right?

–
palladium

3

Hi palladium (nice nick… :wink: ).

0 - Yes, it’s a gui program.

1 - Yes, I installed it on the interface as root. I usually do that when I install programs that have to much “interface” in the installation procedures (installations that are not console only).

2 - I just ran the program as the user I was logged in, i.e., root. I usually do that in order to make sure that everything has gone fine. Tried both the “shotcut” it created in the pannel, as well as the directly path on the terminal. Both ran ok for root, none for other users if on kde or gnome. :frowning:

I find it really strange that root can run it anywhere anytime anyhow. And “common” users must be on fwm or xfce. It doesn’t make any sense to me. Any ideas?

4

NEVER EVER LOGIN AS ROOT ON A DESKTOP, rather do not login as root anyway (I know there are exceptions). Use

su -c 'program parameters'

to run things with root permissions.

Acting against the above, causes trouble like you’re meeting right now. Was this in the installation instructions?

5

I really don’t remember if that was in the instructions. Anyway, I usually have an open session as root on server/firewalls. Easier to do everything that has to be done on these systems, plus an extra visible eye looking over the system

I’ve didn’t, and never did, anything too stupid. Specially leaving a session unattended. Logins as root are used to simplify the very few installations that are needed, and for supervision of any issues, as well as a fast response to any trouble. Mainly, it all means that: we only use root login to install programs of known procedence that also has a GUI interface for the installation/configuration procedures (I think this is at the most the third program with gui installation among the douzains that). Ok, also gdmsetup , when ran, once in a lifetime, also on gui as root.

Finally, this problem seems to be too specific to be dependent on whether I made the installation logged on the GUI as root or not. But, ok, this is my opinion.

Considering that I messed up thing behaving like this this time. What should I do?

6

johannesrs wrote:
> Considering that I messed up thing behaving like this this time. What
> should I do?

i don’t know how to fix it…but the fact (in my mind) that it is a
permissions problem pointed me to the probability that it was
installed incorrectly…

you do you want, but i say never ever ever log into kde/gnome/etc as
root…because no matter how much time you think you are saving,
eventually you WILL run into very strange situations like this one…

always log into kde/etc as a normal user and ‘become root’ as needed,
via YaST, or a terminal session where you are logged in as root…do i
need to repeat this? let me try a different way: there are no, zero,
nada administration duties which REQUIRE you to log into kde/etc as
root…since never required and ALWAYS dangerous–just don’t do it.

read more on all that here:

http://en.opensuse.org/SDB:Login_as_root
http://docs.kde.org/stable/en/kdebase-runtime/userguide/root.html
http://tinyurl.com/6ry6yd
http://tinyurl.com/ydbwssh

oh, i think i may know how to fix your current problem…

uninstall the program, completely as root (NOT logged into KDE/etc as
root) but using the command line to run rpm, or YaST (which, when
launched by a regular user automatically ASKS for the root pass), or
how ever you installed it, undo it…completely…and, on each lab
machine find the hidden directory associated with that program, like
~/.[programName]

then, install the program again, correctly…and, maybe it will work,
correctly…

and, i have a question for you: how does your school, university, or
whatever give back to and further the cause of this openSUSE community
specificially, or Linux generally?

–
palladium

7

I agree with you that it has an inherent unsafety on this behaviour. I just consider that, for very rare and special cases, and for really short periods of time, it can be an option.

And anything I can do with yast I do logged as normal user, then give the root password. Anything that can be done in the terminal, also, su or sudo. But installations that require gui and cannot be performed as a “common” user are simply boring. Not even unix-like for me, and in these cases I open an exception.

About the problem, I’m tracking it down, and seems that I narrowing it to two extra options (other than faulty installations): or it’s an issue with the 32bits version of the program, or it’s an issue with the memory requirements of both kde or gnome and any of the mgltools. I’m trying to look into these options right now to be certain before a full uninstallation.

About the last question, sorry for my english, but could you rephrase it please? I could not properly understand it, and I don’t want to give a wrong answer on something in behalf of the group/institute/university. :wink:

8

johannesrs wrote:

> And anything I can do with yast I do logged as normal user, then give
> the root password. Anything that can be done in the terminal, also, su
> or sudo. But installations that require gui and cannot be performed as a
> “common” user are simply boring. Not even unix-like for me, and in these
> cases I open an exception.
>
In any case if there is an exception it is better to run a graphical
installer which requires root priviliges with gnomesu or kdesu (depending on
your environment) than to login to a desktop as root.
That is what these commands are for and it minimizes a little bit the risk
to screw something by accident. And afterwards I would never, really never
start the application as root to test if it works.

At least this is my opinion (I am NOT a specialist in system administration
but only a developer who often needs to perform some limited amount of
administrative tasks to get the work done).

9

I have little to no idea why it does work within a fwm- / XFCE-session, but anyway, I was curious and downloaded the program myself, guessing that an application like this could also be installed as a regular user, similar to for example Google Earth.

And yes, that worked ootb (on KDE4 by the way), the program runs fine here. So I suppose instead of installing it systemwide via root, you should install it separately for every user. As I said, it works pretty much like Google Earth, which, when installed as root, would only be available for root (since the binaries are installed in the respective ~ and not in $PATH).

While I also recommend never to log into a GUI-session as root, I am sure it has nothing to do with the effects you are experiencing.

10

johannesrs wrote:
> About the last question, sorry for my english, but could you rephrase
> it please? I could not properly understand it, and I don’t want to give
> a wrong answer on something in behalf of the group/institute/university.

sure, but first i hear people say “for very rare and special cases,
and for really short periods of time, it can be an option.” but no one
can list for me the rare and special occasion in which the only way
to do the task that must be done is to log into KDE/Gnome/etc as root…

so please tell my your list of approved rare and special cases.

now, i know that there is a system made in Washington State that folks
all over the world log into as the administrator so they don’t have to
be bothered with a peon user that can’t do everything on there own
machine–GREAT for them, and look how insecure they are…you can make
Linux insecure, all you have to do is ignore all the little security
things that keeps the bad guys away…

and, be advised you do NOT have to be logged on as root more then 30
seconds to make it impossible to subsequently log in with your user
level password!

now, to my last para in the previous:

you have a room full of computers running Linux, for which neither
you, nor the university nor students were required to purchase a
single license…that software, and the help you get here is free of
cost because volunteers give their time and effort to you…

sure, there is some corporate sponsorship but by and large the biggest
part of the Linux work done does not take place on a company
payroll…we are a community…how can, and will you, your students,
and university help the open source community?

i’m not asking for money, i’m completely unpaid here, as we all
are…what i am trying to do is plant a seed:

Give back to the community in whatever ways you can, please…

there are plenty of jobs for plenty of people, see:
http://en.opensuse.org/How_to_Participate

tell me, have the menus, pop-ups, warnings, help files, the wiki, and
etc been translated into your native language? do the non-english
users in your country have the chance to use openSUSE, or any Linux…

just something to think about…and, act on when you can…

–
palladium

11

gropiuskalle wrote:

>
> I have little to no idea why it does work within a fwm- / XFCE-session,
> but anyway, I was curious and downloaded the program myself, guessing
> that an application like this could also be installed as a regular user,
> similar to for example Google Earth.
>
> And yes, that worked ootb (on KDE4 by the way), the program runs fine
> here. So I suppose instead of installing it systemwide via root, you
> should install it separately for every user. As I said, it works pretty
> much like Google Earth, which, when installed as root, would only be
> available for root (since the binaries are installed in the respective ~
> and not in $PATH).
>
> While I also recommend never to log into a GUI-session as root, I am
> sure it has nothing to do with the effects you are experiencing.
>
>
Just for fun downloaded the x86_64 version and installed it from my standard
user desktop session with kdesu (root privileges) and it works afterwards as
standard user (tested with two accounts I have on my PC).

So there are two options available (global with kdesu and user specific with
the suggestion from gropiuskalle) to install it properly without login as
root into the desktop.

12

First of all: thanks to all users for introducing me to the option of kdesu and gnomesu. I was REALLY not aware of these two.

palladium, I’m certain that even my short list is not a proper list. I’m sure that there are ways around using a root login (like the one I just met above, kdesu). But actually, my list of actions in which I usually considered it necessary to be logged in as a root comes down to:

1 - installation of application in which the installation procedure has a gui, and which I want/need it to be available for all users. Now I know I can use kdesu for that. This list of applications basically meant the “sun compiler suite” (wrong name, right idea), now the mgltools and, not sure, but possibly vmd also uses a gui. All other software installed here can be done by console, terminal, and so on, and that is the way it was done.

2 - Ok, the **** ******* ATI drivers, installed in the “hard way”, are so boring that usually were pretty convincing. Next time I’ll try them with kdesu also. :wink:

Finally, concerning how the institution helps: The institution doesn’t. How users helps: some does. Specially “spreading the word” that it can be easily used and works better than any other systems, in their laptops (finally I’ll have mine now too! :smiley: ).

Moreover, we have for some time now tried to help people in the portuguese community susebr, and also have found and taken to light a few problems in some old suse 11.0 packages (we are still doing the same for opensuse 11.2, tracking down where are the errors). Also, we are pushing an science packages openfate that is opened. Some of the requests we have made there, including for cluster operation, and specially the gromacs-openmpi and gromacs-mpich becoming packages officially is a long days idea that I have in mind, but did not have the time needed to make it come true. If that openfate rises or not, it will decide how exactly this will take place.

Actually, I’m deeply involved into making multiterminal opensuse machines. 11.2 made it become much easier than it was with 11.1, but has mad a choice on gdm that turned it into hell. Fortunatelly, the XFCE:Nilda project (if anyone can point me to a more clear dierection of what is that project concerned I would be really thankfull) made a perfect packing of gdm 2.20 and it’s now almost a party to implement. I’ve created an portuguese and bad tutorial on this for 11.0 and 11.2, and now with the new packages I’m going to create a new one, much better, for 11.2.

Ok, some of the users have given up suse for ubuntu, but that’s life. We as a group have being pushing suse in the university instead of debian, readhat, and alikes, for… More than 10 years now. We have even bought a license for version 9.3. I even think that our pushing is what at a certain time finally meant that suse was introduced in one lab of the supercomputing center here for courses sometime ago. I’m not aware of the actual situation there.

Ok, there is always the possibility to do more, but I think we are not just “using the community as our slaves”.

Tomorrow I’ll try to test if the memory is an issue with that program.

Anyway, thanks a lot for all help! :wink:

Edit: By the way, take a look at the bottom of the group webpage: http://www.iq.ufrgs.br/theochem . I agree, it’s not blue, but green didn’t agree very well with the overall color of the site. :wink:

13

martin_helm, one question which might be important for johannesrs too: when installing the MGLTools as root, did you choose a certain directory for the binaries, libs etc.? I’m asking because by default they get installed in ~, which in case of root would be /root, to which a regular user does not have any access to.

14

gropius, unless I’ve made a serious mistake, and I really doubt it from what I’m seeing here, these sort of programs are always installed in /opt/something. Ok, I agree, I discovered too late that I should install them on a different place, but now it’s too late.

du -sh mgl*/*/*
204K    mgltools.1.5.4.32bits/MGLTools-1.5.4/Data
16K     mgltools.1.5.4.32bits/MGLTools-1.5.4/LICENSES
69M     mgltools.1.5.4.32bits/MGLTools-1.5.4/MGLToolsPckgs
8.0K    mgltools.1.5.4.32bits/MGLTools-1.5.4/README
5.3M    mgltools.1.5.4.32bits/MGLTools-1.5.4/bin
1016K   mgltools.1.5.4.32bits/MGLTools-1.5.4/include
75M     mgltools.1.5.4.32bits/MGLTools-1.5.4/lib
2.1M    mgltools.1.5.4.32bits/MGLTools-1.5.4/tcl8.4
1.4M    mgltools.1.5.4.32bits/MGLTools-1.5.4/tk8.4
1.3M    mgltools.1.5.4.32bits/MGLTools-1.5.4/uninstall
204K    mgltools.1.5.4.64bits/MGLTools-1.5.4/Data
16K     mgltools.1.5.4.64bits/MGLTools-1.5.4/LICENSES
69M     mgltools.1.5.4.64bits/MGLTools-1.5.4/MGLToolsPckgs
8.0K    mgltools.1.5.4.64bits/MGLTools-1.5.4/README
6.0M    mgltools.1.5.4.64bits/MGLTools-1.5.4/bin
1016K   mgltools.1.5.4.64bits/MGLTools-1.5.4/include
73M     mgltools.1.5.4.64bits/MGLTools-1.5.4/lib
2.1M    mgltools.1.5.4.64bits/MGLTools-1.5.4/tcl8.4
1.4M    mgltools.1.5.4.64bits/MGLTools-1.5.4/tk8.4
1.3M    mgltools.1.5.4.64bits/MGLTools-1.5.4/uninstall

If you could please compare your directory tree with that, I would be really thankfull. But at a first sight seems that everything is in there.

15

gropiuskalle wrote:

>
> martin_helm, one question which might be important for johannesrs too:
> when installing the MGLTools as root, did you choose a certain directory
> for the binaries, libs etc.? I’m asking because by default they get
> installed in ~, which in case of root would be /root, to which a regular
> user does not have any access to.
>
>
When I installed with kdesu (in kde4 forgot to mention it) the installer
preselected

/usr/local/MGLTools-1.5.4

as default installation path and I used it.
The exact command was simply


kdesu /home/martinh/Downloads/MGLTools-1.5.4-linux-x86-64-install

and the current directory from which I invoked the command was
/home/martinh/Downloads/

I wanted to see what happens when I install with kdesu from the arbitrary
path where I downloaded the installer within my home directory (and if that
influences somehow the path where the application is installed - obviously
not).
(Of course I made the binary executable before that).

16

Just an additional info:

I also selected to install desktop icons which lead to the creation of a
group MGLTools-1.5.4 in the kde menu.
From which users can start the applications.

The binaries are installed in a way you cannot directly invoke for example
“pmv” from the command line (because the installation dir is not in the
path.

But it works well with the absolute path


/usr/local/MGLTools-1.5.4/bin/pmv

(or klicking the menu entries)

17

When I installed with kdesu (in kde4 forgot to mention it) the installer
preselected

/usr/local/MGLTools-1.5.4

Ah okay, then the installer is more clever than I thought. /usr/local is actually the perfect path for such kind of installs according to the Filesystem Hierarchy Standard. Thanks for the feedback!

18

thank you sir, for your personal efforts for the open source
community! am VERY happy to see you are one of us and not just a
user of us…

i sometimes irritate folks here because i so often try to get across
the notion of keeping the actions of user and the administrator
completely separate (even if both are the same person)…

i have to do it irritatingly often here because it comes up almost
every day with new posters…and funny enough they also haven’t heard
of kdesu/etc and their experience with Redmond systems tells them they
can continue doing it the MS way but “just be careful and quick”…

because you are an instructor, i went out of my way to try and make it
very clear because i want you to help set your students off on the
right, non-MS, path…

perhaps installing as root in the GUI didn’t cause the problem you
encountered (i see some here don’t think that was the problem) but,
until proof is offered otherwise, i will continue to believe if it had
been installed ‘correctly’ the problem would have never been seen…

–
palladium

19

Hi all.

First of all, thanks for all the help.

Second, again, thanks for the introduction to kdesu and gnomesu commands. Now it will be easier to really avoid using root gui any time.

Really, I’ve never came across those commands.

Now, as some pointed out, it REALLY wasn’t the installation. And, against all odds: memory. Just jumped it from 1 giga to 2 giga and voi-lá, it worked flawlessly.

It’s a shame that, since that machine became a video-card killer for some reason (possibly some childhood issues… :smiley: ), it will not be usable as a multiterminal, and so will have to be terminated in a near future. No problem, we loose a dual-head one, but will keep the quad-heads that are on the way already. :wink:

Btw, when those are finished, if someone could help me with the translation to English of the coming tutorial, I would be really thankful.

20

it should be easily (?) possible to find someone willing to help…do
you foresee the tutorial as an addition to the read only how-to for
the fora (‘submitted’ via
http://forums.opensuse.org/new-user-how-faq-read-only/unreviewed-how-faq/),
or as a page in the wiki? perhaps in the support data base:
http://en.opensuse.org/SDB:SDB

or, as a stand alone article, such as http://en.opensuse.org/Skype

i really don’t have a good understanding on why there needs to be
three different avenues or places that useful information is stored
(but there are!)…

maybe you should make contact in
http://forums.opensuse.org/opensuse-wiki-discussions/

–
palladium