FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Embedded

 
 
LinkBack Thread Tools
 
Old 12-14-2009, 04:14 PM
Ed W
 
Default emerge --root : users not created

Yep, seems like a known bug

Also the bug exists if you merge in a binary package I believe?

Quite annoying - workarounds would be highly appreciated!

Ed


Shinkan wrote:

Hi everyone,

I posted this on gentoo-user initially, but someone answered and
advised to post this to embedded :


I wanted to submit this as a bug on bugzilla, but I must be sure there
is nothing that I miss.


Let's say I have a /target dir.
If I do 'emerge --root=/target <someport>' (cross-emerge), and that
<someport> is supposed to create users (like vixie-cron, clamav or
many others), users are not created on /target. I can verify that by
chrooting on /target and making something that requires this user
(such as launching clamd for clamav), or simply by looking at
/target/etc/passwd to see that there's no expected users.


Am I missing somethings or is this really a bug ?


Here is "Willie Wong" answer :

If you don't get a better answer here, you should ask the embedded
group. But I think it maybe a bug:

Looking at eutils.eclass, in function enewuser, it explicitly checks
for whether the shell specified is available in ${ROOT}, but when it
comes time to create the actual user, it calls the system useradd,
which I think will add the user to /etc, and not ${ROOT}/etc...

Though, I cannot right now think of how to actually change it so that
it will create the appropriate accounts in a modified ${ROOT}. AFAIK
useradd does not support this. It may require re-implementing useradd
in portage? Which will just be silly.

Perhaps ${ROOT} is not designed to be used the way you intend to use
it? It looks like you are building embedded or cross-compiled, right?
Maybe a work-around is to do everything in a CHROOT?

Anyway, ask gentoo-embedded to see if there's any work arounds, and
maybe ask gentoo-dev to clarify on what $ROOT is used for?

Thanks in advance.

--
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts.
I wonder why we think faster than we speak. Probably so we can think
twice." - Bill Watterson
 
Old 12-14-2009, 04:47 PM
Sven Rebhan
 
Default emerge --root : users not created

2009/12/14 Ed W <lists@wildgooses.com>:
> Yep, seems like a known bug

It's not exactly a bug but rather a missing feature in useradd and
friends. The correct way to solve this would be to add an option to
useradd, allowing to specify a passwd file other than /etc/passwd.
Afterwards patch the corresponding eclass to use this option. Patches
are welcome. ;-)

> Quite annoying - workarounds would be highly appreciated!

To install a cross-compiled system read:
http://gentoo.mindzoo.de/index.cgi/wiki/Cross Install

Especially the command:
find /var/db/pkg -name '*.ebuild' -exec grep -qF 'pkg_postinst()' {}
; -exec ebuild {} postinst ;

which re-executes all post-install procedures on the target system
(and thus adds the users).

Regards,
Sven
 
Old 12-14-2009, 05:06 PM
Peter Stuge
 
Default emerge --root : users not created

Sven Rebhan wrote:
> The correct way to solve this would be to add an option to useradd,
> allowing to specify a passwd file other than /etc/passwd.
> Afterwards patch the corresponding eclass to use this option.
> Patches are welcome. ;-)

Looking at useradd.c at least four filenames should be changed;
passwd, shadow, group and sgroup.

The password db abstraction does allow easy changing of the file
names, but home directory, skel directory, mail spool and probably
more should also be changed, so maybe it makes sense to simply have
useradd call chroot() according to an option early on in main()?


//Peter
 
Old 12-15-2009, 06:31 AM
Sven Rebhan
 
Default emerge --root : users not created

2009/12/14 Peter Stuge <peter@stuge.se>:
> The password db abstraction does allow easy changing of the file
> names, but home directory, skel directory, mail spool and probably
> more should also be changed, so maybe it makes sense to simply have
> useradd call chroot() according to an option early on in main()?

This might be an option. However, I do not know if there are certain
security implications that come up with this change!? The best would
be to discuss this upstream first.

Sven
 
Old 12-15-2009, 07:53 AM
Daniel Glaser
 
Default emerge --root : users not created

Hi,
> ...
> Looking at useradd.c at least four filenames should be changed;
> passwd, shadow, group and sgroup.
>
> The password db abstraction does allow easy changing of the file
> names, but home directory, skel directory, mail spool and probably
> more should also be changed, so maybe it makes sense to simply have
> useradd call chroot() according to an option early on in main()?
>
This will definitely not work on cross targets? I think, there is not a
real workaround for post-installes that need to run on the target
plattform, according to my experience. I always emerged such packages on
the target itself, leading sometimes to very high compilation times.

The cleanest way would be an execute stack that gets created/extended
while cross building and processed when the target starts the next time,
but this would mean a really huge work amount to implement in ebuilds
and the system itself.

Cheers,
Daniel
 
Old 12-15-2009, 09:33 AM
Peter Stuge
 
Default emerge --root : users not created

Daniel Glaser wrote:
> > so maybe it makes sense to simply have useradd call chroot()
> > according to an option early on in main()?
>
> This will definitely not work on cross targets?

Why not? useradd doesn't fork, it does all file IO on it's own, so I
think it could work.


> I think, there is not a real workaround for post-installes that
> need to run on the target plattform, according to my experience.

If useradd is the only problem I think it's easy enough to solve.


> The cleanest way would be an execute stack

Again, if useradd is the only problem, I think that is huge overkill.
It would be a very cool solution though.


How does e.g. T2SDE solve this problem?


//Peter
 
Old 12-15-2009, 12:31 PM
Ahmed Ammar
 
Default emerge --root : users not created

On Tue, 2009-12-15 at 11:33 +0100, Peter Stuge wrote:
> Daniel Glaser wrote:
> > > so maybe it makes sense to simply have useradd call chroot()
> > > according to an option early on in main()?
> >
> > This will definitely not work on cross targets?
>
> Why not? useradd doesn't fork, it does all file IO on it's own, so I
> think it could work.

Well how exactly do you expect chroot to succeed when the host is x86
and the ${ROOT} is arm?

A.
 
Old 12-15-2009, 01:00 PM
Shinkan
 
Default emerge --root : users not created

2009/12/15 Ahmed Ammar <b33fc0d3@gentoo.org>





Well how exactly do you expect chroot to succeed when the host is x86

and the ${ROOT} is arm?


To some questions I read :
I use a amd64 host to build amd64 targets environments.
I use cross-emerge and not crossdev or chroot because my target don't have and WILL NOT have portage, gcc, make or any other build-related tool. My targets will run on livecd, so they won't even have (tmp-excluded) writing needs.


My build needs REQUIRES by process that I could not even put gcc/portage/etc on my target, chroot and build with them, then remove them.

For now, I think of chrooting to useradd manually, or copying some pre-generated /etc/{passwd,shadow,group,...} to my target dir.



I do think it's a bug, because man emerge says that --root is supposed to do everything emerge could do but somewhere else.
If I emerge locally a ebuild that makes a user, I expect emerge --root=/target to also make users on /target filesystem.




--
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I wonder why we think faster than we speak. Probably so we can think twice." - Bill Watterson
 
Old 12-15-2009, 04:37 PM
Peter Stuge
 
Default emerge --root : users not created

Ahmed Ammar wrote:
> > > > so maybe it makes sense to simply have useradd call chroot()
> > > > according to an option early on in main()?
> > >
> > > This will definitely not work on cross targets?
> >
> > Why not? useradd doesn't fork, it does all file IO on it's own, so I
> > think it could work.
>
> Well how exactly do you expect chroot to succeed when the host is
> x86 and the ${ROOT} is arm?

It should work fine. Note chroot() system call, not the chroot
utility.

useradd is a C program and my idea is to make it use the chroot()
system call. This system call changes the root directory for the
calling process. The chroot utility uses this system call, and then
executes a shell or other program inside the new root. The utility
will of course not work cross platform.

As long as the useradd C program does not rely on other executables
at runtime, which I severly doubt considering the nature of the
program, calling chroot() early in useradd would work regardless of
what binaries, if any, are inside the new root dir. useradd only
touches the user database text files.


//Peter
 
Old 12-15-2009, 09:24 PM
Ahmed Ammar
 
Default emerge --root : users not created

On Tue, 2009-12-15 at 18:37 +0100, Peter Stuge wrote:
> Ahmed Ammar wrote:
> > > > > so maybe it makes sense to simply have useradd call chroot()
> > > > > according to an option early on in main()?
> > > >
> > > > This will definitely not work on cross targets?
> > >
> > > Why not? useradd doesn't fork, it does all file IO on it's own, so I
> > > think it could work.
> >
> > Well how exactly do you expect chroot to succeed when the host is
> > x86 and the ${ROOT} is arm?
>
> It should work fine. Note chroot() system call, not the chroot
> utility.

Thanks for clearing that up, makes much more sense now.

A.
 

Thread Tools




All times are GMT. The time now is 07:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org