Bug#860467: apt-setup https protocol support in generators/91security for security mirror
Package: apt-setup Severity: normal Dear Maintainer, This observation resulted from working on a preseed configuration for a Ubuntu install, while attempting to use an internal security mirror we have for security.ubuntu.com. This mirror uses https, which after much debugging/digging is not a supported protocol by apt-setup for security_host and security_path. Currently in generators/91security there is a bit of hardcoding that forces this to use the http protocol. There is no way to override this like with mirror/protocol. Unfortunately we had to create a non-https mirror of security.ubuntu.com as a stop-gap result. It would be nice if there was an equivalent way to set this protocol as mirror/protocol. Preferably, this could be apt-setup/security_protocol to coincide with the existing parameters (secuirty_host and security_path). Example proposed preseed: d-i apt-setup/services-select multiselect security d-i apt-setup/security_protocol string https d-i apt-setup/security_host string internal.mirror.net d-i apt-setup/security_path string /current/security.ubuntu.com/ubuntu Example resulting security mirror: https://internal.mirror.net/current/security.ubuntu.com/ubuntu This was also requested additionally per a conversation in #ubuntu-devel: [17:15] DPK_, there is one more key for protocol i think [17:15] but i can't remember if we ask that for security too, let me check quickly [17:16] (cause we support http, ftp, https) [17:17] == sergiusens [~sergiusen@181.111.178.194] has quit [Remote host closed the connection] [17:17] DPK_, ha, we do not it is hardcoded to http [17:17] for the security [17:18] DPK_, i think you may need to apply sed to either generators/91security during install; or in the install hook; or post install. [17:18] DPK_, could you please open a bug report against apt-setup requesting to support apt-setup/security_protocol key? -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-66-generic (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#860472: apt-setup: switch fallback mirror from ftp.debian.org to deb.debian.org?
Package: apt-setup
Severity: normal
We have a few places with a default mirror, e.g. debootstrap, and we've
had a few changes over the years with http.debian.net and other things.
Lately, we seem to have standardized on deb.debian.org, which might be a
good fallback for apt-setup too:
kibi@armor:~/debian-installer/packages/apt-setup/generators$ git grep
ftp.debian.org
92updates: echo "# deb http://ftp.debian.org/debian/ ${codename}-updates
$dists" >> $file
92updates: echo "# deb-src http://ftp.debian.org/debian/
${codename}-updates $dists" >> $file
93backports:echo "# deb http://ftp.debian.org/debian/ ${codename}-backports
$dists" >> $file
93backports:echo "# deb-src http://ftp.debian.org/debian/
${codename}-backports $dists" >> $file
Comments/objections?
KiBi.
Bug#860467: apt-setup https protocol support in generators/91security for security mirror
Hi Daniel, Daniel Khodaparast (2017-04-17): > This observation resulted from working on a preseed configuration for a > Ubuntu install, while attempting to use an internal security mirror we have > for security.ubuntu.com. This mirror uses https, which after much > debugging/digging is not a supported protocol by apt-setup for security_host > and security_path. > > Currently in generators/91security there is a bit of hardcoding that forces > this to use the http protocol. There is no way to override this like with > mirror/protocol. Unfortunately we had to create a non-https mirror of > security.ubuntu.com as a stop-gap result. > > It would be nice if there was an equivalent way to set this protocol as > mirror/protocol. Preferably, this could be apt-setup/security_protocol to > coincide with the existing parameters (secuirty_host and security_path). Right now, the only setting available is apt-setup/security_host, and there's no apt-setup/security_path (“debian-security” is hardcoded). Adding support for both shouldn't be too hard but: - we're trying to release stretch, so at some point it would be nice to stop making changes; - https support would be a nice addition but lacking it isn't a regression at this point (as I mentioned on IRC, https support is rather new); also, should it be automatically set to https if the main mirror was selected as https? At this point, I think it would be fair to ask interested people to work on this in a buster branch, not to be uploaded to unstable until the release of stretch? KiBi. signature.asc Description: Digital signature
Re: Starting cups in debian installation with preseed
Hi, Geert Stappers (2017-04-16): > On Fri, Apr 14, 2017 at 11:34:41AM +0200, Laurent Besson wrote: > > Hi, > > > > First excuse for my English, I'm french and it's no very good ! > > > > Is possible to start a service as cups during installation with a preseed? > > > > I tried with : > > /d-i preseed/late_command string in-target cupsd// > > //d-i preseed/late_command string chroot /target ; cupsd/ > > > > /d-i preseed/late_command string in-target service cups restart// > > //d-i preseed/late_command string chroot /target ; service cups restart/ > > > > But none works! If you try anything like “chroot /foo; bar”, you create a shell in the /foo environment, wait for it to return, THEN start the bar command. You're not actually starting the bar command in the /foo chroot. See synopsis in manpage: chroot [OPTION] NEWROOT [COMMAND [ARG]...] It seems cupsd might be daemonizing itself automatically (based on a quick look at its own manpage), but that could have been another issue with starting services during the installation process. > > In a console during installation, i tried : chroot /target ; cupsd > > And it works! > > > > Where's the difference? No, you typed chroot /target, which gave you a different shell, in which you typed cupsd. > If I recall correct are preseed late commands allready in target chroot. That seems incorrect based on documentation: Template: preseed/late_command Type: string Description: for internal use; can be preseeded Shell command or commands to run in the d-i environment as late as possible and based on code, see preseed_command and finish-install.d/07preseed in src:preseed. KiBi. signature.asc Description: Digital signature
Bug#860478: Installation Report
Package: installation-reports Boot method: VirtualBox Image version: http://cdimage.debian.org/cdimage/stretch_di_rc3/amd64/iso-cd/debian-stretch-DI-rc3-amd64-netinst.iso Date: 15:12 17.04.2017 Machine: VirtualBox 5.0.6 under Windows 10; default settings Processor: ? Memory: 5219 Mb Partitions: ? Output of lspci -knn (or lspci -nn): ? Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card: [ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system: [ ] Clock/timezone setup: [ ] User/password setup: [ ] Install tasks: [ ] Install boot loader: [ ] Overall install: [E] Comments/Problems: It may be the bug which is written here: https://www.debian.org/devel/debian-installer/errata.en.html However, I do not know how to use "cirrus as an emulated video chip" and it may be another bug. I have tried to run Debian Installer using the virtual machine. Grub loads normally, but as soon as I try to run any of install options, the following output starts to show in a cycle: [22.296448] INFO: rcu_sched self-detected stall on CPU [22.296494] o0-...: (5248 ticks this GP) idle=001/140002/0 softirq=1172/1172 fqs=0 [22.296516] o (t=5250 jiffies g=-55 c=-56 q=595) [22.296537] rcu_sched kthread starved for 5250 jiffies! g184467440073709551561 c18446744073709551560 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0 NMI watchdog: BUG: soft lockup - CPU#0 stuch for 22s! [systemd-udevd:66] etc...
Bug#860447: Acknowledgement (installation-reports: successful (but operator confusion concerning desktop software installation options))
In fairness, in section 6.3.5.2 of the installation guide, it does say "By default, debian-installer installs the Gnome desktop environment." So my "no useful information" claim is an overstatement. But the way the choices are displayed to the user in the selection menu is still counterintuitive. (And I do realize I'm probably a member of a small subset of users who'd want a window manager and not a full-fledged desktop by default.) Dave
Bug#860472: apt-setup: switch fallback mirror from ftp.debian.org to deb.debian.org?
On Mon, 2017-04-17 at 15:25 +0200, Cyril Brulebois wrote:
> Package: apt-setup
> Severity: normal
>
> We have a few places with a default mirror, e.g. debootstrap, and we've
> had a few changes over the years with http.debian.net and other things.
> Lately, we seem to have standardized on deb.debian.org, which might be a
> good fallback for apt-setup too:
>
> kibi@armor:~/debian-installer/packages/apt-setup/generators$ git grep
> ftp.debian.org
> > 92updates: echo "# deb http://ftp.debian.org/debian/
> > ${codename}-updates $dists" >> $file
> > 92updates: echo "# deb-src http://ftp.debian.org/debian/
> > ${codename}-updates $dists" >> $file
> > 93backports:echo "# deb http://ftp.debian.org/debian/
> > ${codename}-backports $dists" >> $file
> > 93backports:echo "# deb-src http://ftp.debian.org/debian/
> > ${codename}-backports $dists" >> $file
>
> Comments/objections?
I agree we should use deb.debian.org as a 'safe' default mirror. We
should certainly not put a hostname in APT sources that doesn't
correspond to a tightly synched set of servers.
Ben.
--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be
sure.
signature.asc
Description: This is a digitally signed message part
Processed: Re: Bug#860472: apt-setup: switch fallback mirror from ftp.debian.org to deb.debian.org?
Processing control commands: > tag -1 patch pending Bug #860472 [apt-setup] apt-setup: switch fallback mirror from ftp.debian.org to deb.debian.org? Added tag(s) patch and pending. -- 860472: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860472 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#860472: apt-setup: switch fallback mirror from ftp.debian.org to deb.debian.org?
Control: tag -1 patch pending
Ben Hutchings (2017-04-17):
> On Mon, 2017-04-17 at 15:25 +0200, Cyril Brulebois wrote:
> > Package: apt-setup
> > Severity: normal
> >
> > We have a few places with a default mirror, e.g. debootstrap, and we've
> > had a few changes over the years with http.debian.net and other things.
> > Lately, we seem to have standardized on deb.debian.org, which might be a
> > good fallback for apt-setup too:
> >
> > kibi@armor:~/debian-installer/packages/apt-setup/generators$ git grep
> > ftp.debian.org
> > > 92updates: echo "# deb http://ftp.debian.org/debian/
> > > ${codename}-updates $dists" >> $file
> > > 92updates: echo "# deb-src http://ftp.debian.org/debian/
> > > ${codename}-updates $dists" >> $file
> > > 93backports:echo "# deb http://ftp.debian.org/debian/
> > > ${codename}-backports $dists" >> $file
> > > 93backports:echo "# deb-src http://ftp.debian.org/debian/
> > > ${codename}-backports $dists" >> $file
> >
> > Comments/objections?
>
> I agree we should use deb.debian.org as a 'safe' default mirror. We
> should certainly not put a hostname in APT sources that doesn't
> correspond to a tightly synched set of servers.
Thanks for your input, just pushed a patch to master. I should have
mentioned this is the fallback when a mirror wasn't selected, in
this code path:
if [ -n "$protocol" ] && [ -n "$host" ]; then
echo "deb $protocol://${host}${directory} ${codename}-updates
$dists" >> $file
else
echo "# A network mirror was not selected during install. The
following entries" >> $file
echo "# are provided as examples, but you should amend them as
appropriate" >> $file
echo "# for your mirror of choice." >> $file
echo "#" >> $file
echo "# deb http://deb.debian.org/debian/ ${codename}-updates
$dists" >> $file
fi
KiBi.
signature.asc
Description: Digital signature
Re: d-i manual: 3 "jessie" remain in current guide
Hello Steve, Steve McIntyre, on dim. 09 avril 2017 01:53:01 +0100, wrote: > On Sat, Apr 08, 2017 at 05:39:20PM -0700, Vagrant Cascadian wrote: > >So, unless it's implemented outside of the device-tree, or I'm > >misreading that, I'd say it's safe to say it's still disabled. > > On the Mustang, you need to be using the firmware-provided > DTB. Assuming a sane, recent UEFI firmware things USB boot should work > just fine. I got it working for the first Jessie point release too, > after doing a temporary build in > http://cdimage.debian.org/cdimage/unofficial/arm64-mustang/ . > > I've not tested a stretch installation directly on a Mustang > lately. The machine I used for the jessie testing has since been > repurposed as a buildd. I'll see if I can access to test another. Did you manage to have a look? Otherwise, perhaps we could probably assume it's working? Samuel
installation-guide is marked for autoremoval from testing
installation-guide 20170312 is marked for autoremoval from testing on 2017-04-28 It is affected by these RC bugs: 859150: installation-guide: leaves many /tmp/tmp* files behind
