Sipwise systems/VMs works well because we rebuild /etc/ssh/sshd_config
from templates and enable supporting /root/.ssh/sipwise_vagrant_key
while for plain VMs we do nothing, so we have to handle it here.
Change-Id: Ib7eccda1a8b9692da6e581aef47c3ccddeb229f6
When we install a fresh squeeze system we want to avoid the
occasional "Hash Sum mismatch" errors during apt-get runs,
so let's not only cover that via upgrades but also in the
initial installation.
Also cover it for Debian lenny, since it very probably might
be affected as well (unverified though).
Change-Id: I01dbeec5ef2a727e5749be5db3ebea47818ed3b5
With the according SSL setup in place nothing should prevent
us to enable HTTPS by default.
The only issues left here are the usage of https for
our internal management web service on port 3000 and
the usage of HTTPS with approx.
Change-Id: I7c9c3d947c6b880b9145ca83a31c832049c6573a
puppet in jessie depends on ca-certificates/openssl which
cant' be removed therefore. We actually want to have
ca-certificates/openssl on all our systems anyway and
nowadays debootstrap doesn't install tcpd and xauth any longer,
so we can safely skip those package removals for jessie and newer.
The templatedir doesn't need to be set in recent puppet versions
and older versions use a sane default anyway, therefore dropping it.
puppet as present in jessie (and newer) expects 'puppet agent --enable'
to be executed to actually be enabled.
Change-Id: Iae70eaeec6a56bef0e67171aab74482aebb24181
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
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
It allows to test scenarios where ngcp-installer is comming from one PPA
while other packages (like ngcp-templates) are comming from another PPA.
By default NGCP_PPA_INSTALLER is equal to NGCP_PPA,
so we still can define one boot option only:
> ngcpppa=gerrit_MT12345_review777
while for some cases it is useful to define:
> ngcpppa=gerrit_MT12345_review777 ngcpppainstaller=gerrit_MT54321_review778
Change-Id: Icf2fee70db1beaae08e9d9c3eba87c5a836661b7
Also removed sipwise user from 'plain' VM boxes,
it is not necessary there as we use user root in Vagrant.
Change-Id: I84c8ab6b1cd6e9dd7ba94f6871b79bafb153bd4e
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
This is needed to resolve web01 to the proper ip after restarting.
Before it was the boot_int IP (192.168.1.1) now it should be the
ha_int IP (X.X.X.X)
Change-Id: I78969321a09798084955d4d045676dbb83732865
For some reason 'Packages' doesn't work for Carrier 3.x
We had to switch to 'Packages.gz' which works perfectly
on approx cache and should be fine for CE/PRO.
Change-Id: I15ae526aca33f3d819dba11b248882f88b37a1ee
At the moment we use wheezy-backports from repo 'wheezy-backports':
> http://debian.sipwise.com/wheezy-backports wheezy-backports main
which is actually not a Debain repository 'wheezy-backports',
but Sipwise repository 'wheezy-backports':
> http://deb.sipwise.com/wheezy-backports wheezy-backports main
It works currently because debian.sipwise.com and deb.sipwise.com are
the same host. So, we have to switch it to sync codebase with bootenv.git
Change-Id: I735402f3e077b5217f7bfa566b6fa7c0a3240a78
We have to sync deployment.sh in netscript.git and bootenv.git
At the moment netscript.git uses /spce/sipwise.gpg and
bootenv.git /sppro/sipwise.gpg (spce repo is missed in approx).
So, lets use the same code here: /spce/ on CE and /sppro/ on PRO.
Change-Id: Ida01fb110ecc90777b4adc5fe8f4bc2c684814ec
Required for usage with recent kernel versions like 3.16 from
wheezy-backports.
Note: this needs actual testing for all our different builds.
Change-Id: I53a4c276ce265dde18f4d27cba2c6810ac502746
We cannot test web services avialability if they listen eth0 only,
so we have to continue listening localhost (which is fine from
security point of view) to be able to connect nginx/ngcp-panel.
In this case ngcp-system-tests will be fine.
Change-Id: Ia4097461d03be51221c1f622018a7974f3984b44
We're customizing /e/n/i in our ngcp installations anyway
after [grml-]deboostrapping the installation via deployment.sh.
But when installing plain Debian systems we depend on a working
/e/n/i file, which isn't true yet because recently we get the
/e/n/i file copied from the host to the installed system which
doesn't work there then as-is.
Depend on grml-deboostrap v0.67 even though the
--defaultinterfaces option was introduced in v0.64,
but v0.67 is what's targeted for Debian/jessie as well
as the upcoming Grml stable release and we're using that
version already anyway because it's the one present in
the grml-testing repository.
Change-Id: Id48636a16cce25fc6a52b6fcaa3db828b9459484
I have tried to add web_* types using deployment.sh, but we need to
rebuild configs later, so the proper way here is to move it installer
(like we did for performance options).
So, reverting web_* part (last two commits) and stops using function
enable_vm_services in deployment.sh since mr3.6
P.S. vagrant_configuration is the last Vagrant part in deployment.sh
I hope to move it in installer also one day.
Change-Id: I57fcb68b71f51cd39b821fb1f30da658fc68d152
When we use b0 as device name for the bonding device, then
we get a bond0 *and* b0 device, while bond0 isn't used then.
This is slightly confusing and there's no need to do that,
since using "bond0" as device name leads to one configured
bond0 device, which operates as needed.
This also follows best practice as documented at
https://wiki.debian.org/Bonding and
https://www.kernel.org/doc/Documentation/networking/bonding.txt
Change-Id: Icfef7d34991200025821a67569b0708d24a43eef
When executing deployment.sh from outside the Sipwise network
it fails due to:
| --2014-09-16 16:49:04-- http://deb.sipwise.com/autobuild/680FBA8A.asc
| Resolving deb.sipwise.com (deb.sipwise.com)... 77.244.249.93, 2a00:4600:2::c0f:fee
| Connecting to deb.sipwise.com (deb.sipwise.com)|77.244.249.93|:80... connected.
| HTTP request sent, awaiting response... 403 Forbidden
Our existing sipwise.gpg file is now available at
http://deb.sipwise.com/spce/sipwise.gpg for public usage.
Change-Id: I08ca2e8c87b7133f9dc0bab59cb85875c57f065a
We've the fai-setup-storage Debian package in our wheezy-backports
repository (taken from http://jenkins.grml.org/job/fai-binaries/architecture=amd64/184/)
which includes the bugfix 5160db7031
to address the failing execution on empty disk(s) with parted >=3.*.
Change-Id: I3400aa1cd80dc356dbd92767756dc43c596ed138
Copy relevant sp2 commands from modify network.yml
PRO section that will be skipped later.
Don't try to connect to db, on CARRIER nodes the
config is already pointing to db1a and that node
could be not even created. This will reduce,
installation time due to ngcpcfg timeouts.
Change-Id: I54aa56277d2d61344a7e77e794da850b364d2e40
We can select the ha_int IP with ngcpip[1|2] but we should be able
to select the netmask too instead of using the default one
Change-Id: I221df9749107662b0a551800a24830fb577f3678
Add an option to control the reconfig of the network.
On our dev proxmox we don't want to touch the network
on the install phase.
Change-Id: I6a05df7c63389b0c2e2d1bb99da8bbd1e976dc23
On sp1 node, get the files after installer execution.
ngcp-update-[cfg|db]-schema does not deal with initial
files on first execution; it truncates them.
Change-Id: I1276ff5ee5f05e950ef32638e48ec7ebf7376f45
As noticed by Victor the trunk installations using the
development.sh script retrieved the latest version of the
installer, no matter to which repository this binary belonged to
(so even if it's not listed in release-trunk-${debian_release}).
This causes problems when you are using trunk installations and
someone is working on installer on branches, reviewing changes,
etc.
To avoid this problem we take a look at the Packages file of the
according repository instead. This isn't limited only to trunk
builds, but also for the release builds, to avoid any possible
problems with multiple deb files inside the pool directory (which
isn't the case yet, but we *could* do that now).
Change-Id: Ie215e70e9317133750cdf0e4b264a3b2c6f083fa
Remove installing the extra packages on carrier, now the carrier
installer is the one in charge of that.
Add CROLE parameter to installer, this should be empty on
normal PRO installations
Change-Id: Ieb7925e11387999b556f03a25f05d3db58260998
Alexander Lutay
Michael Prokop
Victor Seva