Thanks.
>> from my original message
> from reply by Bruce Dubbs
>> useradd -s /bin/bash -g lfs -m -k /dev/null lfs
>>
>> does not return 0, since it fails to copy from /dev/null.
The return value us 12. ('echo $?' gives 12)
> Does 'SKEL_DIR=/dev/null useradd -s /bin/bash -g lfs -m lfs' work?
No. This (and neither does using SKEL instead of SKEL_DIR) creates the
user successfully, but uses the system /etc/skel directory.
Using something like
'SKEL_DIR=/dev/null useradd -s /bin/bash -g lfs -m -k SKEL_DIR lfs'
fails when trying to copy /dev/null.
changing /etc/default/useradd to have the option 'SKEL=/dev/null' also
fails in the same way.
My guess is that attempting to copy /dev/null as a directory is
what is causing it to fail.
>> The second issue, is that I wasn't able to su or sudo into the new lfs user
>> without setting the lfs user's password. This issue may be self inflicted,
>> since it happened after I played around with the sudoers file, though I
>> think I left it in its original state, and I edited it with visudo. A google
>> search says the issue is somewhat common.
I don't think I described the symptoms well. My sudoers file on two
computers, one of which suffers from the problem has the following lines:
Defaults targetpw
ALL ALL=(ALL) ALL
root ALL=(ALL) ALL
On one computer, an opensuse 11.0 system with default configurations,
this works correctly. Anyone, (including me) can su or sudo to root giving
root's password, and root can su or sudo to any other user (of any type)
in the system, without a password.
One another computer, an opensuse 11.2 system with default
configurations, I played around with the sudo file, leaving it the
same as the other, except for replacing:'root ALL=(ALL) ALL'
with 'root ALL=(ALL) NOPASSWD: ALL'. I replaced the second
line with the first and the behavior did not change.
The symptoms themselves:
I can su or sudo to root, giving password. (correctly)
root can su or sudo back to me with no password. (correctly)
root can su or sudo to system logins, possibly choosing another shell.
(correctly)
Now I add a new regular user (lfs), and don't set a password.
>From root: 'su - lfs'. Result: 'su: incorrect password'.
>From root: 'sudo -u lfs /bin/bash'. Result: works.
>From me: 'sudo su - lfs'. I give root password and 'su: incorrect password'.
>From me: 'sudo sudo -u lfs /bin/bash'. I give root password and it works.
>From me: 'sudo passwd lfs'. give lfs a password
>From root: 'su - lfs'. succeeds.
>From me: 'sudo su - lfs'. succeeds after entering root's password.
After setting a password, jhalfs requested the password once in a while
and did just fine. (well, it was a slow computer, but it did work.)
> That is a sudo setup problem. You want something like
>
> User_Alias ADMIN = <your logname>
> ADMIN ALL = NOPASSWD: ALL
> lfs ALL = NOPASSWD: ALL
The problem is in su, not sudo.
>> It might be worth mentioning that some authentication configurations
>> may require that password be set for the lfs user, even if you su from
>> root.
>
> If needed, you can 'sudo su - lfs', but that shouldn't be necessary.
That didn't help in that case since su didn't work.
>> 'patch <options> $SRC_DIR/patch-name.patch'. (and the tar
>> This would allow the sources to be in a read only directory (or device).
>
> That's something to consider. My scripts have:
>
> DIR=`pwd`
> PROGRAM=<program>
> LOG=$DIR/$PROGRAM.log
> BUILDDIR=/tmp/<program-base>
> ...
> cd $BUILDDIR
> tar -xf $DIR/$PROGRAM.tar.?z* || exit 1
> cd $PROGRAM
> patch -Np1 -i $DIR/...
> ...
>
> But that's a little more advanced. We want to keep the build as simple
> as possible. It's up to the user to add customizations. Preferably
> after the first successful build.
Actually creating such scripts is more advanced, and that is what I was
trying to do, (until I decided to first try jhalfs before my own scripts).
I think setting a $SRC_DIR is useful because it doesn't force the build
directory to be in a specific place. In that sense, I think it is educational
to recommend separating 'work directories' from 'data archive' directories.
--Yaacov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
