Sinterklaas is daar bijna en u zoekt nog het ideale geschenk?
Deze email nieuwsbrief werd in grafisch HTML formaat verzonden. Als u deze tekstversie ziet, verkiest uw email programma gewone tekst emails. U kan de originele nieuwsbrief online bekijken: http://sendmail.itdude.be/zQ1q7X View this email online ( http://sendmail.itdude.be/zQ1q7X ) Bezoek webshop ( http://www.fluffyking.com/ ) SINTERKLAAS IS DAAR BIJNA EN U ZOEKT NOG HET IDEALE GESCHENK? Fluffy King is een Belgisch bedrijf dat de zachtste woonaccessoires ter wereld creéert. De dierenkoppen zijn er voor de allerkleinsten, maar ook aan de volwassenen werd er gedacht. Bezoek onze webshop ( http://www.fluffyking.com/ ) WILLIAM William is van nature wat tegendraads. Met zijn tartan uitzicht schept hij ongetwijfeld een unieke sfeer in het interieur. De Schotse ruit is al eeuwen populair, Reindeer William brengt deze nu op een ludieke manier binnen in de woning. Bezoek William ( http://www.fluffyking.com/wildandsoft/abstract-line/william/ ) CARLOS Op zoek naar een fris en vrolijk item om jouw interieur net dat tikkeltje meer te geven? Rhino Carlos voldoet aan al deze eisen. Zijn vorm is pure fun en zijn fluwelen look zorgt voor een intieme, maar toch speelse touch. De kleur is origineel en zorgt steeds voor een zomerse sfeer in huis. Bezoek Carlos ( http://www.fluffyking.com/wildandsoft/abstract-line/carlos/ ) BASILE Hey ik ben Basile de ijsbeer. Ik ben groot, sterk, maar vooral heel zacht. Mijn dikke vacht beschermt mij tegen de kou. Maar ik ben er zeker van dat jouw knuffels mij ook zullen verwarmen. Ik vind het fantastisch om me te laten glijden op mijn buik en ben dan ook een echte speelvogel. Maar ik kan ook stilletjes luisteren naar al jouw avonturen. En wees gerust…jouw diepste geheimen zijn veilig bij mij. Bezoek Basile ( http://www.fluffyking.com/wildandsoft/plushen-lijn/basile/ ) CESAR Ik ben Cesar en men noemt mij ook wel ‘King of the jungle’. Hoewel ik het leuk vind om de baas te spelen, ben ik heel charmant. Wat je niet mag vergeten is om af en toe door mijn manen te wrijven, want ik ben heel trots op mijn gouden haardos. Ik ben heel sterk, moedig en wijs. Samen kunnen we de wereld aan! Bezoek Cesar ( http://www.fluffyking.com/wildandsoft/plushen-lijn/cesar/ ) WWW.FLUFFYKING.COM ( HTTP://WWW.FLUFFYKING.COM/ ) Copyright 2014 www.fluffyking.com, All rights reserved. Not interested in our newsletter? unsubscribe ( http://sendmail.itdude.be/ugjwmyejgsghwbwsygywuggeuheus ).
Bug#768945: busybox lzo implementation suffers from CVE-2014-4607 flaw
Source: busybox Version: 1:1.22.0-5 Severity: serious Tags: security patch upstream fixed-upstream Busybox embeds mini-lzo library implementation which suffers from CVE-2014-4607 -- integer overflow with memory corruption potential and a risk of (remote) code execution, see http://www.openwall.com/lists/oss-security/2014/06/26/20 for details. This flaw has been fixed in busybox upstream in commit a9dc7c2f59dc5e92870d2d46316ea5c1f14740e3. /mjt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110105759.26128.19795.reportbug@gandalf.local
Processed: tagging 768945
Processing commands for cont...@bugs.debian.org: tags 768945 + pending Bug #768945 [src:busybox] busybox lzo implementation suffers from CVE-2014-4607 flaw Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 768945: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768945 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14156172615804.transcr...@bugs.debian.org
Re: d-i talk at Cambridge mini-DebConf
Cyril Brulebois wrote: Joey, I can't really convey this by email, but the last slide was received with warm applause. Thank you so much, for everything. I caught this email yesterday while having lunch with my Mom and Sis and was proud to show them the last slide. They kindly didn't mention the tears. Looking over the presentation again, it's really great to see how much work has gone into d-i this cycle. Well done all. -- see shy jo signature.asc Description: Digital signature
Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8
Hi, On Dienstag, 28. Oktober 2014, Didier 'OdyX' Raboud wrote: It is; let's settle on 8 for the netboot images then; I'll re-upload later today. This upload hasn't reached sid yet (and will still to go through NEW). I've spoken with Didier this morning about it and he said he currently has no time to upload. Debian Edu uses the package to setup PXE installations, and so this is currently broken and I'd like to fix this by uploading the package. Is that ok? I guess I would be willing to add myself to uploaders too and stay responsible for the package... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8
Holger Levsen hol...@layer-acht.org (2014-11-10): Hi, On Dienstag, 28. Oktober 2014, Didier 'OdyX' Raboud wrote: It is; let's settle on 8 for the netboot images then; I'll re-upload later today. This upload hasn't reached sid yet (and will still to go through NEW). I've spoken with Didier this morning about it and he said he currently has no time to upload. Debian Edu uses the package to setup PXE installations, and so this is currently broken and I'd like to fix this by uploading the package. Is that ok? It'd probably a better idea to wait until src:linux migrates to testing, then think about uploading d-i (possibly including some more packages for which unblock requests have been filed), then only d-i-n-i. (You'd get kernel module version mismatch very soon if you were to upload d-i-n-i right now.) I guess I would be willing to add myself to uploaders too and stay responsible for the package... Great! Mraw, KiBi. signature.asc Description: Digital signature
Bug#768914: netcfg/wireless_wpa is type string, not type password
On Mon, Nov 10, 2014 at 05:07:25PM +1100, Trent W. Buck wrote: I just installed wheezy over WPA and ran into #694068. While investigating that, I grepped for my PSK across /. I found it in /var/log/installer/cdebconf/questions.dat under netcfg/wireless_wpa. It is stored in cleartext; the file is only readable by root. In templates.dat (same dir), I see Name: netcfg/wireless_wpa Type: string Description: WPA/WPA2 passphrase [...] Since it's a PASSPHRASE, shouldn't it be Type: password? Normal users cannot read questions.dat, so I don't think this is an immediate problem. (FWIW hostapd's wpa_psk_file option lets each device have its own PSK, so when Mallet is sacked and his PSK is revoked, he can't simply spoof Alice's MAC and use his PSK to get in. I don't use EAP-TLS client certs because support for that is depressingly limited. This means my PSKs are more secret than your typical home network where there's one shared PSK that everyone knows.) That discussion popped up earlier. The problem with Type: password is that you don't see what you're typing in d-i and this may be desirable given long complex passphrases (the over the shoulder attack was discarded). Sadly there's no easy way to toggle display in debconf (yet). But then this is the first time I read about this use of PSK instead of normal EAP keying. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: It's not for the sysvinit-core package to fix up the installer's handling of consoles, when sysvinit-core is not installed. Reassigning this to the debian-installer package. And how could it possibly be debian-installer's job to modify a file that is part of your package, when the package is not installed? I find your response incomprehensible. This bug is about making sure inittab, part of sysvinit-core, supports the console on the platform is is running on. Currently sysvinit-core is defective in not doing so. My comment about debian-installer was just so that you could see an example for code that handles this, and it explains why the maintainers of this package coincidentally haven't had to worry about this problem thus far. One way or another, to reproduce this problem all one needs to do is to install sysvinit-core on a xen VM, with debian-installer nowhere in sight. I also don't understand why #745260 was fixed (exactly the same problem) and this one somehow not. Ok, I misunderstood what the bug was that you were reporting. I thought you were saying that the installer sets up /etc/inittab, but that this doesn't cause the console to work on systems where sysvinit-core is not being installed. I think fixing bug #745260 in sysvinit-core is dubious; I really think that the console setup should be done as part of the installer, not as part of init's maintainer scripts. However, since we are no longer installing sysvinit-core, it's a legitimate question whether the installer should be changed to create /etc/inittab on its own if it doesn't already exist, or if the installer should entirely hand over control of this file to the sysvinit package. I think we should get input from the installer team on this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110184318.ge7...@virgil.dodds.net
Processed: bug 761423 is forwarded to https://bugs.busybox.net/show_bug.cgi?id=7436
Processing commands for cont...@bugs.debian.org: forwarded 761423 https://bugs.busybox.net/show_bug.cgi?id=7436 Bug #761423 [busybox] busybox: using find in pipe with dd produce semi-random output Set Bug forwarded-to-address to 'https://bugs.busybox.net/show_bug.cgi?id=7436'. thanks Stopping processing here. Please contact me if you need assistance. -- 761423: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761423 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14156451674365.transcr...@bugs.debian.org
Bug#761423: marked as done (busybox: using find in pipe with dd produce semi-random output)
Your message dated Mon, 10 Nov 2014 21:56:28 +0300
with message-id 54610a5c.6080...@msgid.tls.msk.ru
and subject line Re: Bug#761423: busybox: using find in pipe with dd produce
semi-random output
has caused the Debian Bug report #761423,
regarding busybox: using find in pipe with dd produce semi-random output
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
761423: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761423
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: busybox
Version: 1:1.22.0-8
Severity: normal
Dear Maintainer,
probably the problem is in the mainstream but it affect also Debian.
* What led up to the situation?
I was trying to find a shell way to check if a directory is empty
* What exactly did you do (or not do) that was effective (or
ineffective)?
I created a chroot with only busybox and the libs needed (as shown by ldd) to
be sure it is using only busybox commands.
sudo chroot chrootdir /bin/busybox sh
created a shell function:
isempty() { [ $(find $1 -name ?* | dd bs=$((${#1}+3)) count=1
2/dev/null) = $1 ] ; }
mkdir /test /test/.x
while [ 1 ] ; do if ! isempty /test ; then echo error ; break ; else echo not
empty ; fi ; done
run it few times
run 1 to 3 exit immediatly with error
run 4 show a non emtpy then error
run 5 show 9 non empty then error
(nobody removed or added files in /test)
also running manually the command below show different results from time to time
find /test -name ?* | dd count=1 2/dev/null
* What was the outcome of this action?
output truncated randomically, seem by line ending, when is wrong show only the
first line.
* What outcome did you expect instead?
always the same predictable full output of find.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.14-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages busybox depends on:
ii libc6 2.19-10
busybox recommends no packages.
busybox suggests no packages.
-- no debconf information
---End Message---
---BeginMessage---
13.09.2014 23:00, Alex Andreotti wrote:
isempty() { [ $(find $1 -name ?* | dd bs=$((${#1}+3)) count=1
2/dev/null) = $1 ] ; }
mkdir /test /test/.x
while [ 1 ] ; do if ! isempty /test ; then echo error ; break ; else echo not
empty ; fi ; done
run it few times
run 1 to 3 exit immediatly with error
run 4 show a non emtpy then error
run 5 show 9 non empty then error
(nobody removed or added files in /test)
also running manually the command below show different results from time to
time
find /test -name ?* | dd count=1 2/dev/null
I'm not really sure this is a bug, and upstream thinks it is not a bug.
The thing is: when you tell dd to exit after first input block,
the next thing is entirely timing-dependent.
`find' applet outputs names as it finds them, using standard buffered
output routines. These are usually configured to perform line-buffering.
So once `find' finds a first file matching the criteria, it prints its
name in one write(2) operation. What happens next depends on timing.
If `find' finds another file and will manage to write it BEFORE `dd'
will be able to consume first file written, dd will read both, because
the pipe between the two is just a stream, each time you read from it
you can read all available data.
Or, dd is free to read first filename before `find' writes second, --
in this case, dd will write first filename and exit, because it is
asked to process just one data block.
* What was the outcome of this action?
output truncated randomically, seem by line ending, when is wrong show only
the first line.
* What outcome did you expect instead?
always the same predictable full output of find.
If you want predictable _full_ output, the only way to get it,
I think, is to use `iflag=fullblock' option. Unfortunately it
is non-standard GNU dd extension, and is not implemented by
busybox. Maybe a wishlist item for busybox dd is in order...
Meanwhile, I'm closing this bugreport, because, as described,
it is not a bug really.
Thanks,
/mjt---End Message---
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On 11/10/2014 01:43 PM, Steve Langasek wrote: On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: It's not for the sysvinit-core package to fix up the installer's handling of consoles, when sysvinit-core is not installed. Reassigning this to the debian-installer package. And how could it possibly be debian-installer's job to modify a file that is part of your package, when the package is not installed? I find your response incomprehensible. This bug is about making sure inittab, part of sysvinit-core, supports the console on the platform is is running on. Currently sysvinit-core is defective in not doing so. My comment about debian-installer was just so that you could see an example for code that handles this, and it explains why the maintainers of this package coincidentally haven't had to worry about this problem thus far. One way or another, to reproduce this problem all one needs to do is to install sysvinit-core on a xen VM, with debian-installer nowhere in sight. I also don't understand why #745260 was fixed (exactly the same problem) and this one somehow not. Ok, I misunderstood what the bug was that you were reporting. I thought you were saying that the installer sets up /etc/inittab, but that this doesn't cause the console to work on systems where sysvinit-core is not being installed. I think fixing bug #745260 in sysvinit-core is dubious; I really think that the console setup should be done as part of the installer, not as part of init's maintainer scripts. However, since we are no longer installing sysvinit-core, it's a legitimate question whether the installer should be changed to create /etc/inittab on its own if it doesn't already exist, or if the installer should entirely hand over control of this file to the sysvinit package. I think we should get input from the installer team on this. I don't really see how it makes sense to create an /etc/inittab when we're installing systemd (silently and without asking). Without sysvinit, inittab doesn't belong there and doesn't make sense. The way I see it, the only way the installer can be of help here is if it is changed to prompt the user for his init system choice, which AFAIK wasn't the decision so far.. though it would please me very much! Otherwise we're sort of pre-creating a file for a hypothetical purpose.. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546114e7.9090...@gedalya.net
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
Hi, Steve Langasek vor...@debian.org (2014-11-10): On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: It's not for the sysvinit-core package to fix up the installer's handling of consoles, when sysvinit-core is not installed. Reassigning this to the debian-installer package. And how could it possibly be debian-installer's job to modify a file that is part of your package, when the package is not installed? I find your response incomprehensible. This bug is about making sure inittab, part of sysvinit-core, supports the console on the platform is is running on. Currently sysvinit-core is defective in not doing so. My comment about debian-installer was just so that you could see an example for code that handles this, and it explains why the maintainers of this package coincidentally haven't had to worry about this problem thus far. One way or another, to reproduce this problem all one needs to do is to install sysvinit-core on a xen VM, with debian-installer nowhere in sight. I also don't understand why #745260 was fixed (exactly the same problem) and this one somehow not. Ok, I misunderstood what the bug was that you were reporting. I thought you were saying that the installer sets up /etc/inittab, but that this doesn't cause the console to work on systems where sysvinit-core is not being installed. I think fixing bug #745260 in sysvinit-core is dubious; I really think that the console setup should be done as part of the installer, not as part of init's maintainer scripts. However, since we are no longer installing sysvinit-core, it's a legitimate question whether the installer should be changed to create /etc/inittab on its own if it doesn't already exist, or if the installer should entirely hand over control of this file to the sysvinit package. I think we should get input from the installer team on this. let's pretend for a moment that I know nothing about inittab, and that I'm focussing on installation scenarios only, not upgrades. It looks to me that this is an issue different from yet similar to the one described in [1], where systemd w/o dbus would lead to no console on vt 2-6. 1. https://lists.debian.org/debian-boot/2014/11/msg00127.html Would it make any sense to have $something created by d-i, consumed by both systemd and sysvinit to make sure consoles are available? If maintainers of both systems can come up with something suitable for everyone, let's do that? Maybe some kind of /etc/inittab.compat which could be created by d-i and could be defaulted to by relevant packages in case /etc/inittab is missing and yet needed? Of course if I'm conflating issues that are orthogonal, please say so and we'll track both issues separately. Mraw, KiBi. signature.asc Description: Digital signature
Processed: tagging 768876
Processing commands for cont...@bugs.debian.org: tags 768876 + pending Bug #768876 [busybox] busybox-static is statically linked against libc6, but doesn't have a Built-Using: field Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 768876: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768876 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14156534974533.transcr...@bugs.debian.org
Re: Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On Mon, Nov 10, 2014 at 02:41:27PM -0500, Gedalya wrote: On 11/10/2014 01:43 PM, Steve Langasek wrote: On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: It's not for the sysvinit-core package to fix up the installer's handling of consoles, when sysvinit-core is not installed. Reassigning this to the debian-installer package. And how could it possibly be debian-installer's job to modify a file that is part of your package, when the package is not installed? I find your response incomprehensible. This bug is about making sure inittab, part of sysvinit-core, supports the console on the platform is is running on. Currently sysvinit-core is defective in not doing so. My comment about debian-installer was just so that you could see an example for code that handles this, and it explains why the maintainers of this package coincidentally haven't had to worry about this problem thus far. One way or another, to reproduce this problem all one needs to do is to install sysvinit-core on a xen VM, with debian-installer nowhere in sight. I also don't understand why #745260 was fixed (exactly the same problem) and this one somehow not. Ok, I misunderstood what the bug was that you were reporting. I thought you were saying that the installer sets up /etc/inittab, but that this doesn't cause the console to work on systems where sysvinit-core is not being installed. I think fixing bug #745260 in sysvinit-core is dubious; I really think that the console setup should be done as part of the installer, not as part of init's maintainer scripts. However, since we are no longer installing sysvinit-core, it's a legitimate question whether the installer should be changed to create /etc/inittab on its own if it doesn't already exist, or if the installer should entirely hand over control of this file to the sysvinit package. I think we should get input from the installer team on this. I don't really see how it makes sense to create an /etc/inittab when we're installing systemd (silently and without asking). Without sysvinit, inittab doesn't belong there and doesn't make sense. The way I see it, the only way the installer can be of help here is if it is changed to prompt the user for his init system choice, which AFAIK wasn't the decision so far.. though it would please me very much! Otherwise we're sort of pre-creating a file for a hypothetical purpose.. Are there any other inits that use /etc/inittab? With the plethoors of inits that have showed up over the past decades, it wouldn't surprise me at all if some of them were compatible in this respect. Would it make sense to put /etc/inittab into annother package that sysvinit-core depends on? The way things look right now, with systemd being installed against their wishes, sysvinit users are being told to install sysvinit-core after installation, when they have finally booted the target system. This way, /etc/inittab would be installed for them at the same time. Any other inits could have the same dependency, as apropriate. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110204757.ga19...@topoi.pooq.com
Bug#425859: user-setup: Cannot preseed an installation with a locked (!) root password and no user account
Hi, So has anybody ever found a solution to this? I'm still in the same boat 7 years later with 1.48 of user-setup on ubuntu 14.04. The work-around using !! kind of works but means that the emergency recovery mode in Ubuntu mistakenly thinks that root has a password set and prompts for one which makes it rather useless in an emergency. Cheers, Seb On Thu, 24 May 2007 16:29:05 +0100 Matthew Johnson mjj29-deb...@srcf.ucam.org wrote: Package: user-setup Severity: minor I have been trying to preseed config files for a set of servers we have just bought. Since I do not want either the root password (even hashed) in the config file or any user-interaction on these (headless) machines, I would like to disable both the root password and not create a user. Access is enabled by late_command which installs an ssh public key to /root/.ssh/authorized_keys. The documentation (at http://www.debian.org/releases/stable/i386/apbs04.html.en) says: The passwd/root-password-crypted and passwd/user-password-crypted variables can also be preseeded with ?!? as their value. In that case, the corresponding account is disabled. This may be convenient for the root account, provided of course that an alternative method is setup to allow administrative activities or root login (for instance by using SSH key authentication or sudo) However, a preseed file containing: d-i passwd/make-user boolean false d-i passwd/root-password-crypted string ! or: d-i passwd/make-user boolean false d-i passwd/root-login boolean false still prompts for either the root password or creation of a user. This would appear to be deliberate because user-setup-ask contains: db_get passwd/root-login if [ $RET = false ]; then # always make non-root user; this user will be able # to sudo to root db_set passwd/make-user true and db_get passwd/root-password-crypted || true if ! test $RET || [ x$RET = x! ]; then # No preseed of the root password hash # we will prompt the user This, however, is not what the documentation claims or what would be useful in this case. I have currently solved the problem by using the following preseed: d-i passwd/make-user boolean false d-i passwd/root-password-crypted string !! but it would better if the actual implementation matched the documentation and if the situation I would like were supported. As an additional wishlist item; user-setup could do the preseeding of ssh public keys for users or root itself and therefore explicitly support this case. No patch yet; maybe if I have time. Matt
Bug#425859: user-setup: Cannot preseed an installation with a locked (!) root password and no user account
Quoting Sebastian Unger (sebunge...@gmail.com): Hi, So has anybody ever found a solution to this? I'm still in the same boat 7 years later with 1.48 of user-setup on ubuntu 14.04. The work-around using !! kind of works but means that the emergency recovery mode in Ubuntu mistakenly thinks that root has a password set and prompts for one which makes it rather useless in an emergency. Hello Sebastian, Thanks for bringing back this issue. I suspect that actually nobody felt like implementing this (which would indeed require another pressedable variable) mostly because (speculation here) we consider this to be a corner case that can be solved by alternative methods. And then the issue fell under the radar of everybody (the installer team desperately needs people to help triaging bugs) The documentation is indeed unclear more than wrong: it lets you think that you can preseed the locked root password *and* not have a regular user created,; which is not the case. Your (interesting) workaround could however be documented in the installation manual, though. Cheers, Seb On Thu, 24 May 2007 16:29:05 +0100 Matthew Johnson mjj29-deb...@srcf.ucam.org wrote: Package: user-setup Severity: minor I have been trying to preseed config files for a set of servers we have just bought. Since I do not want either the root password (even hashed) in the config file or any user-interaction on these (headless) machines, I would like to disable both the root password and not create a user. Access is enabled by late_command which installs an ssh public key to /root/.ssh/authorized_keys. The documentation (at http://www.debian.org/releases/stable/i386/apbs04.html.en) says: The passwd/root-password-crypted and passwd/user-password-crypted variables can also be preseeded with ?!? as their value. In that case, the corresponding account is disabled. This may be convenient for the root account, provided of course that an alternative method is setup to allow administrative activities or root login (for instance by using SSH key authentication or sudo) However, a preseed file containing: d-i passwd/make-user boolean false d-i passwd/root-password-crypted string ! or: d-i passwd/make-user boolean false d-i passwd/root-login boolean false still prompts for either the root password or creation of a user. This would appear to be deliberate because user-setup-ask contains: db_get passwd/root-login if [ $RET = false ]; then # always make non-root user; this user will be able # to sudo to root db_set passwd/make-user true and db_get passwd/root-password-crypted || true if ! test $RET || [ x$RET = x! ]; then # No preseed of the root password hash # we will prompt the user This, however, is not what the documentation claims or what would be useful in this case. I have currently solved the problem by using the following preseed: d-i passwd/make-user boolean false d-i passwd/root-password-crypted string !! but it would better if the actual implementation matched the documentation and if the situation I would like were supported. As an additional wishlist item; user-setup could do the preseeding of ssh public keys for users or root itself and therefore explicitly support this case. No patch yet; maybe if I have time. Matt -- signature.asc Description: Digital signature
