Re: Debootstrap on GNU/Hurd Status
On Wed, Apr 16, 2003 at 02:29:34PM +0200, Marcus Brinkmann wrote:
> > because glibc sets up update-rc-like stuff in /etc/rc?.d. The hurd
> > package provides update-rc, but apparently not these directories. Either
> > the hurd package should ship these directories, or some other package.
> I ported sysvinit a couple of years ago, and the old and out of date patch
> is in the Debian BTS. It never got any official acknowledgement of any
> type. Privately, I got a reply that the package should be split into an
> (source-wise) architecture independent base package with the programs, and
> an architecture dependent package for the init scripts. That never happened.
> For the Hurd, we want a better init system than sysvinit (Wolfgang seems to
> work on one), but that doesn't exist yet.
> > I'll file a bug against hurd for this issue soon if nobody objects.
> The Hurd package just has a filthy kludge that makes it start the daemons at
> boot time, and allows to use Debian without an init system. The only bug
> report I want to see there is one that says that these kludges can be
> removed (when they can).
> > - The adduser package had to be put explicitely into $required, because
> > hurd's postinst would fail otherwise:
> > /var/lib/dpkg/info/hurd.postinst: line 29: adduser: command not found
> > dpkg: error processing hurd (--configure):
> > subprocess post-installation script returned error exit status 127
> > I'll file a bug about this, too.
> I think at that time base-passwd was arch all, and I didn't want to put the
> special Hurd login user into that. Now this could possibly go into the base
I talked to the base-passwd maintainer on irc about this some days ago.
(Please excuse my obvious lack of clue about the Hurd's login procedure)
Here's the log:
00:48 < azeem> Kamion: the hurd package currenty creates a user 'login'
in its postinst
00:48 < azeem> that's quite a PITA to bootstrap. Would it make sense to
put that into base-passwd propert?
00:48 < Kamion> azeem: can't it just be done with 'adduser --system'?
00:48 < Kamion> I'm not very keen on making the master passwd file
00:49 < azeem> adduser --quiet --system --home /etc/login --gecos
"Not logged in" --no-create-home login
00:49 < Kamion> what's the problem with it at the moment?
00:49 < azeem> that's the current line. The problem is that the hurd
package doesn't depend on adduser
00:49 < azeem> and it's priority: required
00:50 < Kamion> adduser will just have to be priority: required on hurd
then, I suppose (I know we don't have arch-specific overrides yet)
00:50 < azeem> I'm currently hacking around it in debootstrap, but I
wanted to ask
00:50 < azeem> Kamion: well, ok
00:50 < Kamion> the trend in base-passwd has been to decrease the number
of base ids, I'd like to continue that
00:51 < Kamion> I could reserve a uid for it if you wanted, though, if
that would help
00:51 < Kamion> in the 60000-64999 range
00:51 < azeem> I'm not sure. I just encountered that problem while
00:51 < azeem> # Take care that a "login" user exists. Useful for our
00:52 < azeem> that's the comment
00:52 < Kamion> I think it's probably a bug in the hurd package anyway,
TBH I think I'd fix that and worry about the details of overrides
00:52 < azeem> do I'm not sure it's really required. I'll ask jbailey or
00:52 < azeem> Kamion: yeah, ok
00:52 < Kamion> I can see why it might be required, from what I remember
of the hurd
00:53 < azeem> mbanck@raptor:/etc/login$ ls -a
00:53 < azeem> . .. .bash_login .bashrc .hushlogin .profile README
00:53 < Kamion> that wasn't an outright no, btw, just a "please try to
find some other way if possible" :)
00:54 < azeem> Kamion: ok
00:54 < Kamion> what deals with the login-user-has-no-rights thing?
00:54 < Kamion> ISTR it's a super-unprivileged user
00:55 < azeem> hmm, not sure
00:55 < azeem> but yes, it's very unprivileged
01:01 < azeem> Kamion: apparently it's just the set of scripts in the
/etc/login-directory above that does it
01:08 < Kamion> azeem: oh, so there's a "lose-me-all-my-privileges"
01:08 < Kamion> I've often wanted the opposite of newgrp(1), to revoke
one of my own groups
01:09 < azeem> no, not AFAICT
01:09 < azeem> alias login='exec login -p -R-p -R-aHOME -R-aMOTD
01:09 < azeem> PS1='login> '
01:09 < azeem> test "$_LOGIN_RETRY" || echo "Use \`login USER' to login,
or \`help' for more information."
01:09 < azeem> unset _LOGIN_RETRY
01:09 < azeem> this seems to be it
01:10 < Kamion> I thought I'd heard people saying that there was a fourth
set of permission bits that applied to the login user
01:11 < azeem> could very well be, I've never looked into that part of
As debootstrap lets us assign additional packages to be required, this
issue is just a cosmetic one, having adduser in required only on the
Hurd seems a bit hacky.