LPCXpresso installation for LDAP (non-local) user accounts

[timotero]

Hello,

Recently I needed to install LPCXpresso on several Linux computers.

The target was to get a fully functional system for different users of the computer.

However, this seems to fail miserably because the user accounts are stored in LDAP.

This means that the account data is not in the usual (e.g. /etc/passwd) format and it is

always fetched from LDAP (ie from network service).

When installing with such a user account the installation fails, complaining something

about "id user". I suspect that this is due to the "id" command returning data in format

not understood by the installer - or returning more(?) than the installer understands.

So, the installation with LDAP account does not work - at all in my case.

Next, we tried creating local account and installing using that. This works for installing

but fails for LDAP users when trying to run the LPCXpresso (from /usr/local/lpcxpresso...)

With this one the problem seems to be non-local user accounts again but the error

is manifested differently: the LPCXpresso IDE fails to start because the user does not

have enough access rights in the /usr/local/lpcxpresso... directory. Frankly, the user

should not have write access therein at all - but allowing that will enable the IDE for

one user, while others will fail. Again, the problem seems to be with LDAP (vs local

accounts), in this case most likely due to not understanding where the home folder

for (LDAP based) user is. As the home directory is somehow not found, the IDE tries

to write to (default location?) under /usr/local/lpcxpresso... and that is (naturally) owned

by "root" account.

As this was tried in a setup where I do not myself have "root" account rights I cannot say

whether there is issues coming from the system itself. However, considering that the

Installation executable really complains about the LDAP user starting the installation, I would

say there is something wrong in the installation media.

So, far the only ways we get this working are:

* using local account only: both for installation and running the IDE

* installing into user directory by copying an installation

Neither of these is a good solution. Both require considerable amount of additional work to get the IDE running properly.

This system setup is used temporarily for research purposes and we need to have efficient way of deploying the system.

A working solution would be really appreciated, thanks!

Timo

[lpcxpresso_supp]

Timo

If you change the workspace to a directory that you know exists do you still see the problem?

Sincerely
LPCXpresso IDE Support

[timotero]

Is it possible that the software used to create the installer has an issue?

One of the professors found this article:

InstallJammer / Bugs / #313 When using non local users the installer fails immidiately 

Can you check the 8.2.2 against this? It is an old one but seems like 100% match

with what we see.

If there is a quick fix you would get +40 testers :-) however for the coming sessions

(Tuesday and Wednesday) we need to use workaround...or we are prepared to use.

BR

Timo

[lpcxpresso_supp]

Hi Timo

It does look as if there is a bug in InstallJammer.  Unfortunately this third-party program is no longer supported, so we intend to move away from this method of installation on Linux and use .deb and .rpm files instead.

In the meantime, I note that you are able to use it when you log on as root, and this is probably your best work-around (to the install problem).

If InstallJammer had worked properly it would have logged you on as root in any case.

Installation on Linux will always require root privileges.

Sincerely
LPCXpresso IDE Support

[timotero]

Here is the log from Installer* tried. I have removed user and PC related information.

./Installer_LPCXpresso_8.2.2_650_Linux-x86
unknown user id: #UID_NUMBER_REMOVED#
    while executing
"id user"
    (procedure "::InstallJammer::CommonInit" line 228)
    invoked from within
"::InstallJammer::CommonInit"
    (procedure "::InstallJammer::InitInstall" line 18)
    invoked from within
"::InstallJammer::InitInstall"
    (file "/installkitvfs/main.tcl" line 39322)

#WS_NAME_REMOVED#:(/wrk3)(54)% id #USER_NAME_REMOVED#
uid=#UID_NUMBER_REMOVED#(#USER_NAME_REMOVED#) gid=251(fys) groups=251(fys)

As a local user

[lpcxpres@#WS_NAME_REMOVED# wrk3]$ ./Installer_LPCXpresso_8.2.2_650_Linux-x86

(When logged in with ssh, gives warnings but then asks for root password and installation succeeds)

[lpcxpres@#WS_NAME_REMOVED# wrk3]$ id lpcxpres
uid=666(lpcxpres) gid=100(users) groups=100(users)

When run under local account, all the dot-directories are written into home directory. When run under ldap account, dot-directories are written into installation directory (if write-access is given), owned by this ldap account. With another ldap account the program again fails.

If I log in with ldap account, rename /etc/passwd and start the installation, the error is same

#WS_NAME_REMOVED#:(/wrk3)(52)% ./Installer_LPCXpresso_8.2.2_650_Linux-x86
unknown user id: #UID_NUMBER_REMOVED#
    while executing
"id user"

...

so the installation really insist on reading /etc/passwd. Installation should be made ldap-aware. Or totally independent of the underlying authentication mechanism...

Timo

[lpcxpresso_supp]

Hi

LPCXpresso is designed to be installed by 'root' on Linux.  It cannot normally be installed by specific users.

Installation problem

Your problem looks very much as if the installer (created by a third party tool 'installjammer') can not confirm that you are 'root'.  Usually, if you are not 'root' it offers a dialogue to help you log on as root.  It may be possible to work around this problem simply by running the installer as root.

Multiuser suport

I'm afraid the product has few accommodations for a multi-user environment (other than using the normal arrangements made in the eclipse base product).  Nonetheless we believe that what there is is sufficient for its use on a serially reused machine.

There may be issues arising if two users tried to use the product simultaneously because only a single daemon is launched to service all debug connections in the machine and it is normally accessed only by the user who launched it.

Runtime problem

the LPCXpresso IDE fails to start because the user does not

have enough access rights in the /usr/local/lpcxpresso... directory.

After a normal installation these files will owned by 'root' but have read and execute permissions as required.

The normal POSIX file access controls should allow every user access under the final ('all') permission bits.

You should be able to confirm this by inspection...

Perhaps you have additional access controls defined (e.g. with secure linux)?

Frankly, the user should not have write access therein at all - but allowing that will enable the IDE for

one user, while others will fail.

In normal operation no write access to files in this directory is required (or allowed). 

Perhaps writes are being attempted here because the application (which is run from inside this directory) has not selected the user's home directory as you suggest in your comment:

As the home directory is somehow not found, the IDE tries

to write to (default location?) under /usr/local/lpcxpresso... and that is (naturally) owned

by "root" account.

This is possible.  The product locates the home directory using the HOME environment variable.

Could you check that this environment variable is set and that it has an accessible value?

(It would also be worth checking that value of environment variable USER to see if it is sensible too.)

Remote user database use

Again, the problem seems to be with LDAP (vs local accounts), in this case most likely due to not understanding where the home folder for (LDAP based) user is.

This does seem to be a component of your problem, but normally the distinction between different kinds of user database is handled by Linux in such a way as to be equivalent to applications.  The file /etc/nsswitch.conf determines where various system calls obtain their user (and other) information from so that applications need not know.

The nature of this file is to list a series of user databases that are used in turn (in the order provided) by the system.  Even if it is set to use ldap you may find that it appears together with 'files' as a backup.  (In this context 'files' will mean Linux accesses /etc/passwd.)

Applications such as ours, particularly cross-platform ones, should never attempt to access user data bases (e.g. local file /etc/passwd) themselves - only use the relevant system calls.  I would be very surprised if we used anything other than standard POSIX system calls.

Although I may be wrong, I think there is little more than the value of $HOME (and possibly $USER) that the product depends on in respect of user information.  (Although this may not be the case in the installer.)

Another possibility is some problem in the LDAP support being used?

[timotero]

Thank you. We will study the problem further. At least the "HOME" seems to be correctly initialized.

Also, there is no other application suffering from similar symptoms.

In the case of LPCXpresso there is issues with running the application. Installation requires root but

still results in system that cannot be run by ordinary LDAP-authenticated users. LDAP-authenticated

(ordinary) user cannot even install because the setup fails before asking for "sudo password". With local

account this works AND local account can use the IDE too.

With local account the user data is stored within $HOME (in directory .eclipse, I think) - but the LDAP

authenticated accounts seem to ignore this and go work in the installation directory. Another thing we

see is that the default workspace folder is offered with "?/" as part of the part, e.g. something like

"/home/username/?/LPCXpresso/workspace" which indicates some odd problem too. Similar to

this there is a directory with "%" name in the installation area.

We do not actually need a multi-user installation in the sense that all the machines are being used

by only one account at any given time. So there is no conflict with starting networked debugger with

same server port: only one instance of IDE is running. But it should work with different user names

without problems - otherwise there is no way to make the installations beforehand.

It is possible that the LDAP is the root for this problem - even if it works for everything else.

We will study it further.

[lpcxpresso_supp]

Hi

Another thing we

see is that the default workspace folder is offered with "?/" as part of the part, e.g. something like

"/home/username/?/LPCXpresso/workspace" which indicates some odd problem too.

This is consistent with the IDE deciding that the user's home directory is /home/username/? - as if the user's name were "username/?"

Could you provide a sample of the actual value of $USER and $HOME for one of your LDAP users to see if it gives us any further clues?

Sincerely
LPCXpresso IDE Support

[timotero]

Examples for USER and HOME variables:

lastu22:(~)(52)% echo $USER

pollari

lastu22:(~)(53)% echo $HOME

/home/fys/pollari

These are from LDAP authenticated user.

BR

Timo