Le vendredi 12 décembre 2014 à 09:27 +0100, Patrick Ohly a écrit :
> On Thu, 2014-11-27 at 11:28 +0100, José Bollo wrote:
> > Le jeudi 27 novembre 2014 à 10:23 +0100, Patrick Ohly a écrit :
> > > Hello!
> > > 
> > > It hasn't become clear to me in the gumd and image creation discussions
> > > whether .rpm postin/un scripts can still depend on useradd and userdel
> > > to create users for system services (example: avahi daemon runs as user
> > > "avahi") dynamically.
> > > 
> > > If so, what are the right runtime dependencies (if any) to ensure that
> > > the commands are really available?
> > > 
> > > If not, then I guess we maintain a static configuration of such daemons
> > > and never modify it during package install/uninstall? Again, avahi is a
> > > good example, because that's what's currently done for the "avahi" user
> > > (see
> > > https://review.tizen.org/gerrit/#/admin/projects/platform/upstream/setup).
> > > 
> > 
> > Hi Patrick,
> > 
> > That is a real problem. I advocated on this list to have gumd providing
> > a legacy scripts: useradd.... We will switch to gumd very soon (see
> > https://review.tizen.org/gerrit/#/c/30885/ ). 
> 
> That was merged. But it doesn't remove anything, so do we still have the
> useradd/remove commands and are allowed to use them?
> 

Hello Patrick,

Yes we put in images all these novelties! And are planning to light it
on asap.

So yes gumd is in the image.

As you know I was advocating for having in gumd wrappers for the old
useradd/groupadd/userdel/groupdel commands. 

But frankly, I had no real feedback on this proposal and I was not
expecting to have to do it. 

I know from Kevin and Ronan that you are facing issues about user
creation in yocto but dont understand much what it is exactly. More
explaination would help.

I put at the end of this mail the result of the commands "rpm -ql gumd"
and "rpm -ql pwdutils" that are showing the content of the to projects.

From my (not very clear) understanding, in tizen/common/obs the project
platform/upstream/setup is included but not in tizen-yocto project.
Well, why not.

So here actors are:
 - pwdutils
 - gumd
 - setup

And knocking at the door the "giant" novelty of systemd-sysuser that I
heard about 3 days ago.

IMHO, the guidelines should be:
 - as least as possible definitions in setup
 - use useradd and other pwdutils programs
 - making gumd supply a replacement for pwdutils feature
 - not use systemd-sysuser (just for blowing on embers and opening the
debate ^_^)

But to be more compliant to yocto it seems that it is not what have to
be done.

Best regards
José Bollo





















root@lenovo06:~# rpm -ql gumd
/etc/dbus-1
/etc/dbus-1/system.d
/etc/dbus-1/system.d/gumd-dbus.conf
/etc/gumd
/etc/gumd/gumd.conf
/usr/bin/gumd
/usr/share/dbus-1/system-services
/usr/share/dbus-1/system-services/org.tizen.SecurityAccounts.gUserManagement.service
/usr/share/doc/packages/gumd
/usr/share/doc/packages/gumd/AUTHORS
/usr/share/doc/packages/gumd/COPYING.LIB
/usr/share/doc/packages/gumd/NEWS
/usr/share/doc/packages/gumd/README
/usr/share/gumd.manifest

root@lenovo06:~# rpm -ql pwdutils
/etc/default/passwd
/etc/default/useradd
/etc/login.defs
/etc/pam.d/chage
/etc/pam.d/chfn
/etc/pam.d/chsh
/etc/pam.d/passwd
/etc/pam.d/shadow
/etc/pam.d/useradd
/etc/pwdutils
/etc/pwdutils/logging
/usr/bin/chage
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/expiry
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/sg
/usr/lib64/pwdutils
/usr/lib64/pwdutils/liblog_syslog.so.1
/usr/lib64/pwdutils/liblog_syslog.so.1.0.0
/usr/sbin/chpasswd
/usr/sbin/groupadd
/usr/sbin/groupadd.local
/usr/sbin/groupdel
/usr/sbin/groupmod
/usr/sbin/grpck
/usr/sbin/grpconv
/usr/sbin/grpunconv
/usr/sbin/pwck
/usr/sbin/pwconv
/usr/sbin/pwunconv
/usr/sbin/useradd
/usr/sbin/useradd.local
/usr/sbin/userdel
/usr/sbin/userdel-post.local
/usr/sbin/userdel-pre.local
/usr/sbin/usermod
/usr/sbin/vigr
/usr/sbin/vipw
/usr/share/licenses/pwdutils
/usr/share/licenses/pwdutils/COPYING




_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to