Also removed sipwise user from 'plain' VM boxes,
it is not necessary there as we use user root in Vagrant.
Change-Id: I84c8ab6b1cd6e9dd7ba94f6871b79bafb153bd4e
(cherry picked from commit d689c13fc8)
Since lvm2 v2.02.106 its udev rule creates a
/dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for PVs:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=417e52c13a8156b11c25c411d44bda8b32bf87e4
When debootstrapping Debian/wheezy to a virtio disk from a system
using lvm2 >=v2.02.106 (as present in Grml >=2014.11) this causes
the resulting GRUB installation to look like that
(`/media/ngcp-root` is the mounted logical volume with the rootfs
which also includes /boot):
| root@grml ~ # cat /media/ngcp-root/boot/grub/device.map
| (hd0) /dev/disk/by-id/lvm-pv-uuid-RNZHr8-hLlc-nles-X9Gs-RYSp-Mqo7-uZTk6N
| (hd1) /dev/vda
and failing to boot with:
> error: no such disk
> Entering rescue mode...
> grub rescue>
When manually removing the lvm-pv-uuid* symlink from the
Debian/jessie system before installing GRUB it works fine:
| root@grml ~ # rm /dev/disk/by-id/lvm-pv-uuid-RNZHr8-hLlc-nles-X9Gs-RYSp-Mqo7-uZTk6N
| root@grml ~ # ls /dev/disk/by-id
| ata-QEMU_DVD-ROM_QM00003@ dm-name-ngcp-swap@ dm-uuid-LVM-lQhnvLyYmhESObLrZcnJs4FTZq9usVDzRex3ImRtrmqhpDH9xKBj22St82lHDADh@
| dm-name-ngcp-root@ dm-uuid-LVM-lQhnvLyYmhESObLrZcnJs4FTZq9usVDzrcMaDfk8O0RionEYRxdjnYxsY6eb0Esi@
| root@grml ~ # grml-chroot /media/ngcp-root/ grub-install --recheck /dev/vda # `grml-chroot` makes sure /proc, /sysfs and /dev are properly mounted in the chroot
| Writing /etc/debian_chroot ...
| Installation finished. No error reported.
| root@grml ~ # cat /media/ngcp-root/boot/grub/device.map
| (hd0) /dev/vda
NOTE: This problem seems to exist only for virtio disks, when
using a disk on the SATA bus the resulting device.map of the
Debian/wheezy system looks like that and boots fine:
| root@grml ~ # cat /media/vg0-root/boot/grub/device.map
| (hd0) /dev/disk/by-id/ata-QEMU_HARDDISK_QM00005
| (hd1) /dev/disk/by-id/lvm-pv-uuid-lJJr4E-M96R-3eIS-b6YO-5usn-bH5o-osQV2B
As a result check for Debian wheezy (or older) and if the disk is
a virtio one (AKA /dev/vda), if so then remove the symlink of the
live system before installing Debian incl. GRUB via
grml-debootstrap.
Reported as https://bugs.debian.org/782998 in Debian's BTS.
Change-Id: I4b2cf9e39c88521ab7eac7799531508e658cc30d
(cherry picked from commit 7340bf211c)
During the refactoring in 43c9f159 we missed the point that
/etc/debootstrap/pre-scripts/install-sipwise-key.sh should be
executed on CE install CD too even if we do NOT download key.
Otherwise we are getting:
> Reading package lists...
> W: GPG error: http://debian.sipwise.com wheezy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4EB7765DA42C4F2A
> W: GPG error: http://debian.sipwise.com wheezy-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4EB7765DA42C4F2A
> W: GPG error: http://debian.sipwise.com wheezy-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4EB7765DA42C4F2A
and CE installation failed as unauthorized packages cannot be installed.
Change-Id: I3ccc8b8801ba2be829c4eea84507f11c841b7658
(cherry picked from commit e5664d5850)
Also, we did s/RETRIEVE_MGMT_CONFIG/CARRIER_EDITION/g because /etc/hosts
and /etc/network/interfaces are fully configured for Carrier by ngcp-installer.
So, no need to touch them for Carrier at all now
(see commits to installer.git through this ticket).
Change-Id: Ie16038d1f6c194564bb91c52faab75e86e3a0c11
1) Previously we were installing keys everywhere,
this produces a mess, so lets install them once on start.
2) GRML bypass /etc/apt/trusted.gpg.d/sipwise.gpg to NGCP CHROOT via install-sipwise-key.sh.
So we have /etc/apt/trusted.gpg.d/sipwise.gpg on every installed VM for wheezy/squeezy/jessie.
3) /var/log/deployment-installer-debug.log on all plain and NGCP VMs contains:
> echo "Sipwise Debian mirror key is already present."
So, we can safetely clean it from vagrant_configuration, IMHO.
Change-Id: I873f87faed24df4a93474cf17f41eb19e8a14ab1
We already have a function which take care about the keys,
we should use it everywhere!
Moreover the public keys contains both release and autobuild keys already:
>> http://deb.sipwise.com/spce/sipwise.gpg
>> http://deb.sipwise.com/sppro/sipwise.gpg
> gpg sipwise.gpg
>> pub 1024D/A42C4F2A 2010-11-29 Sipwise GmbH (Sipwise repository key) <support@sipwise.com>
>> sub 2048g/680FBA8A 2010-11-29
>> pub 4096R/EE5E097D 2011-06-06 Sipwise autobuilder (Used to sign packages for autobuild) <development@sipwise.com>
>> sub 4096R/3A5C488C 2011-06-06
Change-Id: I8b729ff624954de0d133b803e4d220c29a4fd799
It's PITA to install an internal system which depends on vlan
tools being present to get network acess but not having vlan
tools installed. So far we installed the vlan plus related tools
only when the vlan boot option was present during deployment
time. This might be relevant also for our ngcp users and it
should be safe to always include those tools. So we decided to
always include vlan (+ related) tools on all our installations.
Change-Id: I17bc5b9aba967d13bebe2db631e9167e693b09bc
We have migrated to ngcp.inc with modern list of services to be stopped
at the end of ngcp-installer.
See commit e75b01441c for more details.
Unfortunately deployment.sh is performing 'magic' with network.yml and depends on glusterfs
for pulling/pushing configs from/to shared storage. I am planning to move this 'magic' to
ngcp-installer, but while it is here, we have to start stop glusterfs-server manually.
Change-Id: Ia0aac183df52a1e2bd51ff6f2326f8438cad5b79
It was a temparary option to check systemd on wheezy while we
were waiting for Jessie. Systemd doesn't work well in wheezy,
we had a problems wil kamailio-config-tests and other components.
So, currently we have Jessie VMs available and no reason to keep the
code here as we are not going to use systemd on wheezy anyway.
Change-Id: I1c35b4e3bdd9718107812e7ac2112e796c2e83b0
We are not using config.yml->{networking}->{hb_device} since ~2.7
We are using ha_int from networking.yml, so, it is a time to clean
deployment.sh and config.yml
Change-Id: Ifb9f9a78d267120db4fa0423ceaacc5309f74eae
At the moment deploymnent.sh file on public website
http://deb.sipwise.com/netscript/master/deployment.sh
contains the commit ID of latest file change, but not
the latest commit ID in repository.
From one side it is correct and useful, but from another side
it confuses a lot when you check the verion is Git/Deb and
on public site http://deb.sipwise.com/netscript/
IMHO, it worth to keep them in sync to prevent confusing.
Change-Id: I7db7949ccc780314146a7eeada3dbf197e3fcb35
Sipwise Jenkins Builder
Alexander Lutay
Michael Prokop
Victor Seva