A root-cert in for Let's encrypt expired on this date:
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021
Our jobs in gerrit installing machines, for example matrix-runner, for
stretch and buster, fail to download packages from debian. and
deb.sipwise.com complaining that the certificate is invalid.
This is because of having older versions of ca-certificates, that don't
contain the new root-cert, or because versions of some libraries
(e.g. gnutls used by wget and apt) do not seem to work well when there
are several chains to validate the certificate -- they use only the
first chain, and if elements of it are invalid/expired, don't try the
others.
This change forces installation of new versions of ca-certificates and
libgnutls30 both in the "outside" system running grml (because it needs
to use "wget" accessing the servers for special commands) as well as
"inside" the new chroot, because by default in the new Debian system
ca-certificates is not installed.
Change-Id: I58ff9daa10c21f5ad867308c33ffa303c120683d
grub-pc >=2.04-11 has a new behavior regarding /boot/grub/i386-pc/
handling, where we end up with an empty /boot/grub/i386-pc/ after
*successful* grub-install execution:
| root@grml ~ # vgchange -ay
| 3 logical volume(s) in volume group "ngcp" now active
| root@grml ~ # mount /dev/mapper/ngcp-root /mnt
| root@grml ~ # grml-chroot /mnt /bin/bash
| Writing /etc/debian_chroot ...
| (spce)root@grml:/# cd
| (spce)root@grml:~# grub-install /dev/sda
| Installing for i386-pc platform.
| Installation finished. No error reported.
| (spce)root@grml:~# ls -la /boot/grub/i386-pc/
| total 16
| drwxr-xr-x 2 root root 12288 Dec 16 12:04 .
| drwxr-xr-x 4 root root 4096 Dec 16 12:07 ..
This causes the installed system to fail to boot with:
| GRUB loading..
| Welcome to GRUB!
|
| error: file `/boot/grub/i386-pc/normal.mod' not found.
| grub rescue> _
The underlying issue is that recent grub versions unlink the files
inside /boot/grub/i386-pc, though it doesn't report anything about it
(even under `--verbose` execution).
This is triggered in our situation, as lvm2's vgs binary isn't present
yet. In earlier versions of grub this wasn't causing any problems and
grub-install happily installed the files inside /boot/grub/i386-pc, even
though we installed lvm2 only afterwards via our metapackages. To
ensure lvm2 is available during installation time within
grml-debootstrap, explicitly add to it list of packages to be installed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977544 for further
details regarding the grub bug.
Change-Id: I27a1cd18777526eb26b838fae88d4d87b6e93467
(cherry picked from commit 91e047a486)
This variable is required to locate check-for-network script.
Change-Id: I7b5792acab6134a47cdbea6793065d674e47a67f
(cherry picked from commit 73327b10f0)
The /usr/bin/python symlink/binary no longer exists in recent
Grml-Sipwise ISOs and python3 doesn't ship SimpleHTTPServer but
http.server instead.
Change-Id: I6677e8a416b142034d99d5b1d2b11ba74d87a6ec
(cherry picked from commit 862fb155f0)
No need to install this package to non-vagrant system.
Do not add this package to Sipwise-grml image - it's too heavy (86M)
and not needed on real systems.
Change-Id: I9ec9ff76d588f4ced30ba199f05bb167eec5288a
Previously the functions and the code were fixed so it was hard to
understand the flow of execution.
Move all functions to a single section at the beginning of the script
so it's easier to understand the code.
Fix shellcheck warnings:
SC2086: Double quote to prevent globbing and word splitting.
SC2154: efidev1 is referenced but not assigned.
Change-Id: Ie4bf28c166e4a9ff236eff807ee97adae6ecddd0
This variable is used in some ngcpcfg *.services file.
Specifically 'ngcp-provisioning-tools/mysql_values.cfg.services' uses
this variable to specify mysql db host and if it's necessary to reload
kamailio.
Change-Id: Ibf137cdd0ad6f6492a30cfa715c468e4ac22832f
Initially wanted to sync with https://github.com/grml/grml-network/ as
of commit 49409a5587d, though templates/scripts/includes/netcardconfig
existed only to provide the VLAN patch until we had this available from
upstream and our own ISO. Now that everything has been upstreamed and we
have up2date Grml ISOs, let's switch to the one included in upstream
Grml.
Change-Id: I685cd0ad95033ad2b50036e53c2ee9814a776e63
Instead of having to maintain this ISO in our web server off-band,
we switch to use the packaged version, which makes validation
unnecessary as apt gives us that. And it also gives us a newer
version (currently 6.0.4 with Debian buster 10.3 vs the old 5.2.26).
Change-Id: Id89280bbe7fadeb35d391b5dc46e930935017588
From the packages' deps and content POV Pro and Carrier packages are
equal to each other so get rid of this separation.
Change-Id: I587dba3147bdc9b3c0f10da820ba4cdc8a0a0f08
* Addon fixes:
* Provide custom addon template according to our needs, instead of
relying on the default one being present in grml-live.git/templates
* Install memtest86+ as addon for BIOS usage
* Install netboot.xyz.lkrn for BIOS usage and netboot.xyz.efi for EFI usage
* Install ipxe.lkrn for BIOS usage and ipxe.efi for EFI usage
* Stick grml-live version to v0.34.3, instead of relying on some random
git master version
* Stick grml2usb version to v0.17.0, instead of relying on the grml2usb
version available on the host system (being 0.14.14 on Debian/stretch as
present on our current build hosts). For arbitrary addon file names we
need grml2iso (which uses grml2usb underneath) from grml2usb >=0.17.0.
FTR, grml2iso and grml2usb can be executed from within the git repository,
assuming all relevant tools are present
* No longer invoke isohybrid on the resulting ISO, instead rely on
grml2iso behaviour (which also checks for EFI support and enables
according switches as needed)
* Fix usage instructions in t/Dockerfile:
* it's "deployment-iso-buster" and not "lua-ngcp-kamailio-buster"
* refer to working directory instead of "deployment-iso.git",
which very probably isn't named as such on any of our systems,
while the $(pwd) approach works for c/p
* Fix docker build usage in grml_build/Dockerfile (for building we need
to provide a PATH (being current working directory for us)
* Provide testing tools in grml-build-buster docker environment
* Provide new testing script t/iso-tester to compare generated ISO
against pre-defined screenshot (only testing memtest feature using
./t/screenshots/01-memtest.jpg for now)
Change-Id: I67e3f85bbe86bd1b3ee709161504b5250ca5d7fe
This reverts commit ee2398b6f8.
We've removed mcollective from our infrastructure and ready to update
puppet to the latest available version.
Change-Id: I7a860be9e051ed09bd69c165aaafc2acd1f17cd8
In the past we were associating them by MAC address and only in some cases, like
Pro/Carrier and in Virtual Machine environments.
However, it's beneficial to have this in other scenarios, so we will create udev
rules to pin them down during deployment.
Change-Id: Ic1b397e81af673b974961158a0e9a05ce5b80a69
This file contains the following public keys:
68A702B1FD8E422AAAA1ADA3773236EFF411A836 - jessie, stretch, buster
debian repos, mr3.8-mr8.4 public repos.
F7B8A739CE638D719A078C9859104633EE5E097D - autobuild repos.
8A61E3C73B6987020226079D69D9C21F6D9B587E - new key for mr7.5+.
This very file will be used only for bootstrap purposes and will be
dropped in the end of installer.
Change-Id: I60a903b4b05ab8a0d1a6498773802f756f8e4202
Initially dirmngr package was installed to allow running apt-key inside
deployment.sh to install puppetlabs key. Then after moving puppetlabs
key to local file package installation was removed. But we still need it
for successful first puppet run that also uses apt-key. Otherwise there
is the error: 'Could not find a suitable provider for apt_key'. Puppet
also installs dirmngr package but in such case only the second puppet run
will be successful so we need to install the package before the very
first puppet run.
Change-Id: I28edbd8c91c841074ac1b3f1eb6df16e14daa084
In deployment.sh line 2109:
local puppet_gpg='/root/puppet.gpg'
^-- SC2168: 'local' is only valid in functions.
Change-Id: I628cbac844db6aa1913ab1747906656d7d6d739b
The puppet.gpg is located in Grml-sipwise so no need to download the
hard-coded key but use the local one.
Change-Id: Id57180de96efef4a5a13086e7807c615bd65b886
In the event of network blips, HA switchovers or failure of the servers, there
might be a problem downloading some of the hundreds or thousands of packages
needed for installation.
Set the option to retry 3 times in the case of such failures, to try to minimise
their impact.
This has to be done in several places because mmdebstrap (which uses apt) and
apt-get are invoked at different points.
Change-Id: I5acbd9895fa37452026e582c241ced945fbba3d7
The boot parameter 'ngcpstatus' is used to wait the number of seconds
before ending process so the external system can retrieve the final
status from 4242 port.
Add the value of this parameter as STATUS_WAIT_SECONDS option to
ngcp-initial-configuration config so external system can track the
configuration stage also.
Change-Id: I68d9c65a1cc96bf581305e92d8b9b6bfc34e7ed2
mmdebstrap and debootstrap install any "important" packages in the
standard installation variants, pulling in e.g. libgdbm5 (which was of
priority `important` until #890832 was fixed and it was downgraded to
priority `optional` with libgdbm6).
Same for libusb-1.0-0 vs libusb-0.1-4:amd64:
% apt-cache show libusb-1.0-0 | grep Priority
Priority: optional
% apt-cache show libusb-0.1-4:amd64 | grep Priority
Priority: important
Resulting in having libusb-0.1-4 *and* libusb-1.0-0 installed on
our NGCP systems, while libusb-0.1-4 is completely unneeded and irrelevant.
So this is unnecessary, and all the other packages that are automatically
pulled in via the standard installation should be handled via according
and explicit dependencies elsewhere, JFTR - currently being in
Debian/buster:
| apt-utils bsdmainutils cpio cron debconf-i18n dmidecode dmsetup
| e2fsprogs gdbm-l10n ifupdown init iproute2 iptables iputils-ping
| isc-dhcp-client isc-dhcp-common kmod less libapparmor1 libapt-inst2.0
| libargon2-1 libbsd0 libcap2 libcap2-bin libcom-err2 libcryptsetup12
| libdevmapper1.02.1 libdns-export1104 libelf1 libestr0 libext2fs2
| libfastjson4 libidn11 libip4tc0 libip6tc0 libiptc0 libisc-export1100
| libjson-c3 libkmod2 liblocale-gettext-perl liblognorm5 libmnl0
| libncurses6 libnetfilter-conntrack3 libnewt0.52 libnfnetlink0 libnftnl11
| libpopt0 libprocps7 libslang2 libss2 libtext-charwidth-perl
| libtext-iconv-perl libtext-wrapi18n-perl libxtables12 logrotate lsb-base
| mount nano netbase procps readline-common rsyslog sensible-utils systemd
| systemd-sysv tasksel tasksel-data tzdata udev vim-common vim-tiny
| whiptail xxd
The essential variant lacks apt(-get), while the minbase variant provides
the same base as essential, *plus* apt so we can actually install
further packages, so that's what we're using.
We pull in systemd + systemd-sysv + init explicitly to force its usage,
ngcp-installer is complaining and prompting otherwise.
We pull in isc-dhcp-client + ifupdown to have a working networking/DHCP
setup after reboot, since we don't use systemd-networkd or alike (yet).
Applying this change will result in lacking the following packages in
our Debian/stretch based trunk builds:
* apt-utils
* blends-tasks
* debconf-i18n
* iputils-ping
* isc-dhcp-common
* libapt-inst2.0
* liblocale-gettext-perl
* libtext-charwidth-perl
* libtext-iconv-perl
* libtext-wrapi18n-perl
* libusb-0.1-4
* logrotate
* tasksel
* tasksel-data
* vim-tiny
The ones we want to have available will be handled via explicit
dependencies in NGCP (meta)packages.
Change-Id: I14dac92d99172cf792a0334601a930ce6698dc83
This variable tells ngcp-installer that it is run from
deployment.sh.
In this case we need it to skip CE warning in ngcp-installer:
===================
This installation script is not intended to run in a shared system,
as it can add/delete/update existing configurations.
Please run this script only in a base install of 64 bit Debian 9 (stretch)
on a dedicated server.
Do you want to continue with the installation process? (y/N):
===================
Change-Id: I9a33ccbe07332a09a64c98a2bef844fa95498c05
By default we should not skip any confirmation messages. In automation
setup we need just change it to 'yes' before
ngcp-initial-configuration.
Change-Id: I1ca69aaa1e19f8e34b82434d99b50e41add74f6f
apt > 1.6 started creating this directory, but older apt versions do not
know how to clean it up. When using a newer host apt than the one that
will be used in the chroot, the chroot apt will be unable to remove it
properly, and will emit a warning.
mmdebstrap was supposedly fixed in version 0.4.0-1, but the code was
inserted before further «apt-get update» calls, so the directory gets
regenerated. We workaround this here for now, after having run
grml-debootstrap which might be calling mmdebstrap depending on the
release.
Change-Id: I13ad1b7ecc9f60414ab7e9222bada10d09baa2ab
Otherwise the servers with Software RAID cannot be
installed due to the error on stage 'grub-install "/dev/$disk"':
> grub-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.
The package grub-pc is a NGCP dependency, so it is available
when we install NGCP but missing when we recovery server using Puppet
or install Debian plain on Software RAID.
Change-Id: I46caf893d2d6c523b6c007702d21f6b81caac291
When bootstrapping into a tmpfs (running inside a VirtualBox VM using a
Grml-Sipwise ISO), debootstrap takes 2min 17seconds, while mmdebstrap
takes only ~20 seconds. This is a notable change that's worth using it
by default.
Quoting mmdebstrap's package description:
| Downloads, unpacks and installs Debian packages to either directly create a
| directory which can be chrooted into, or a tarball of it. In contrast to
| debootstrap it uses apt, supports more than one mirror, automatically uses
| security and updates mirrors for Debian stable chroots, is 3-6 times faster,
| produces smaller output by removing unnecessary cruft, is bit-by-bit
| reproducible if $SOURCE_DATE_EPOCH is set, allows unprivileged operation using
| Linux user namespaces, fakechroot or proot and can setup foreign architecture
| chroots using qemu-user.
Further differences noted between debootstrap + mmdebstrap:
* debootstrap requires exec + dev permissions on the target,
while mmdebstrap doesn't need them (being a good thing, actually)
* mmdebstrap pulls in gnupg1/gpgv1 on the target system (stretch-only),
while debootstrap doesn't
* debootstrap leaves the Debian packages in /var/cache/apt/archives behind,
while mmdebstrap doesn't
* debootstrap leaves the Debian repository files in /var/lib/apt/lists behind,
while mmdebstrap doesn't
* mmdebstrap doesn't consider apt, debconf as Priority 'required' but as 'important',
gcc-8-base, libacl1, libattr1 + zlib1g as 'required' instead of 'optional',
libbz2-1.0 + libpcre3 as 'important' instead of 'optional';
libdb5.3 + libtasn1-6 as 'standard' instead of 'optional'
None of those issues should cause any issues for us, though.
Change-Id: I93616263c2fed45ab8063fce024b98a7c6272660
As we build and use our specific Grml images with all required packages
we don't need to install any additional ones.
Change-Id: I20df3b0e676fc49439cb9a7cfe250e71f71c6238
The version 5.2.18 building is very slow on the recent
Debian stretch kernel 4.9.0-8-amd64:
VBoxGuestAdditions version 5.2.18:
> 12:32:52 (netscript.grml:1854): vagrant_configuration(): grml-chroot /mnt /media/cdrom/VBoxLinuxAdditions.run --nox11
> Writing /etc/debian_chroot ...
> Verifying archive integrity... All good.
> Uncompressing VirtualBox 5.2.18 Guest Additions for Linux........
> VirtualBox Guest Additions installer
> Copying additional installer modules ...
> Installing additional modules ...
> VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules. This may take a while.
> VirtualBox Guest Additions: Starting.
> VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules. This may take a while.
> +12:39:15 (netscript.grml:1856): vagrant_configuration(): ...
VBoxGuestAdditions version 5.2.26:
> +13:35:50 (netscript.grml:1854): vagrant_configuration(): grml-chroot /mnt /media/cdrom/VBoxLinuxAdditions.run --nox11
> Writing /etc/debian_chroot ...
> Verifying archive integrity... All good.
> Uncompressing VirtualBox 5.2.26 Guest Additions for Linux........
> VirtualBox Guest Additions installer
> Copying additional installer modules ...
> Installing additional modules ...
> VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel
> modules. This may take a while.
> VirtualBox Guest Additions: To build modules for other installed kernels, run
> VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
> VirtualBox Guest Additions: Building the modules for kernel 4.9.0-8-amd64.
> VirtualBox Guest Additions: Starting.
> Running in chroot, ignoring request: daemon-reload
> +13:39:12 (netscript.grml:1856): vagrant_configuration():
5.2.26 is the latest stable version from VirtualBox,
reported as such by upstream (see
https://download.virtualbox.org/virtualbox/LATEST-STABLE.TXT)
Change-Id: Ieb4b158344b3e4d0bf2719e8897cdfcdf133082b
Instead of runtime compiling during the installation compile this lib
in package building and deliver as part of the package.
Change-Id: Ic97adb0c958c57976ac5d23974b0efc306ccb326
This is the same solution for a similar problem and that it was implemented in
5ab1f5418a, but extending it to other parts of the
code that did not wait-and-retry.
Apparently commands like "blockdev --flushbufs" (flush buffers of block devices)
do not solve the situation in all cases, so this is a more foolproof --if
inelegant-- solution that should not slow down the deployment more than a few
seconds at most.
Change-Id: If74e134262475ab0b100981f94fa310536f0a7ab
In newer systems it can be under ngcp-data partition (/ngcp-data/home/sipwise),
in older systems without this partition it can be under /var/sipwise.
Also this way is more future-proof, if the location changes again.
Change-Id: If2d3a3b55ea81871071bf846c8ca981e703d3d88
HOSTNAME env variable is not set from 'ip=' but seems to be set
outside of deployment.sh script and exported to it. HOSTNAME
variable is set differently if newer grml20181230 is set in
dnsmasq dhcp.conf. We have 'ip=' option where we explicitly set
hostname for the host so let's use it (instead of uncontrolled
HOSTNAME variable) for puppet installation case.
Change-Id: I3fa2cc7ec982b270302d2d0940d6477b666eaf5c
Manuel Montecelo
Michael Prokop
Mykola Malkov
Guillem Jover
Sergii Kipot
Alexander Lutay