[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).

OK.

> >  - 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
> list.

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 
	arch-specific ...
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 
	porting debootstrap
00:51 < azeem> # Take care that a "login" user exists. Useful for our 
	login shell.
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 
	later ...
00:52 < azeem> do I'm not sure it's really required. I'll ask jbailey or 
	marcus
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" 
	command?
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 
	-R-e_LOGIN_RETRY=yes' 
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 
	the Hurd

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. 

cheers,

Michael



Reply to: