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
We configure ssh_ext for all present network devices (except for
some known to be irrelevant ones like the ones from VMware,
VirtualBox and Docker), instead of just enabling it for
$EXTERNAL_DEV (being eth0 by default). Retrieving the list of
available network devices is done on each of the according PRO
systems separately, so we don't enable it on sp1 for network
devices that possibly aren't available on sp2.
We also explicitly enable ssh_ext for sp2 on sp1 for loopback and
$INTERNAL_DEV (eth1 by default), so we can make sure we can
access ssh at any given time.
1) we don't have /etc/default and/or config.yml options for old releases
2) we need to decreate some option for low performance mode
3) services should never start with default options
(otherwise oom-killer does the job and kill services)
So, we have migrated all the options to installer under special
install option and are going to decrese config _and_ template
for old releases in deployment.sh
In this case VM after first reboot will have all the options in
low performance mode and we do not need apply changes.
In case of DHCP server is being used, and system was rebooted
with new IP, network.yml still has old IP and SSH will listen old IP only.
Vagrant cannot connect VM using old IP to change it to new one.
In case of CE with one network interface (common case)
ngcp-eadresss will update network.yml and apply new config.
PRO should not be installed using DHCP (at least in production).
Vagrant VMs has two interfaces, so ngcp-eadresss does nothing,
so we add option to config.yml which overwrites ssh_ext types in
network.yml.
We have an error "reset: standard error: Invalid argument" in header of
CE install CD, so replated reset with clear which worked well for long time
during the nightly builds.
Also removed all the additional calls for logo() function.
(I have no ideas what can be the reason of broken layout MT#4697,
spent a lot of time trying to catch it, it comes time-2-time,
so currently minimised amount of any functions calls during printing logo).
I hope to catch this one day and fix it in prtoper way.
Debian's BTS has all the details in #750212 which I just reported.
lvm2 version 2.02.106-1 includes a check for present signatures,
and without "--yes" option fai-setup-storage is hanging when
executing lvcreate on a device which includes such a (swap) signature.
We don't want to use the sources.list generation which
grml-debootstrap does, as we want to control 100% of
what we use/deploy, so provide sources.list as needed.
I think we finally tracked down the problem to its roots (oh boy… ٩(͡๏̯͡๏)۶)):
The problem exists only for PRO systems, where we ship the
heartbeat-2 package, which still uses and provides the /usr/lib64
directory (that's what you get for running antique software
*cough*). As soon as this directory exists the
VBoxLinuxAdditions.run script of virtualbox-guest-additions-iso
detects and uses this directory as library path. It installs the
mount.vboxsf symlink using this library path.
The symlink /sbin/mount.vboxsf points to the non-existing
/usr/lib64/VBoxGuestAdditions/mount.vboxsf file instead of
pointing to
/usr/lib/x86_64-linux-gnu/VBoxGuestAdditions/mount.vboxsf.
It works for CE systems, because we don't ship the heartbeat-2
package there. Without heartbeat-2 /usr/lib64 doesn't exist and
VBoxLinuxAdditions.run does the right™ thing by detecting
and using /usr/lib/x86_64-linux-gnu instead.
If that's finally working as expected™ I'll be able to sleep much
better again… ☻
We're still facing:
| root@sp1:~# mount -t vboxsf -o uid=`id -u sipwise`,gid=`getent group sipwise | cut -d: -f3` /vagrant /vagrant
| mount: Protocol error
on some VMs (noticed on e.g. 3.1 PRO system with 3.13-0.bpo.1-amd64).
The /sbin/mount.vboxsf file is missing for some reason we're not
aware of yet.
Let's get rid of unneeded AllowUnauthenticated usages with apt.
It would be even better if we could ship our own key with the
official Grml-Sipwise ISO (which would technically be no problem,
but we need a way for PXE boot for builder.mgm anyway).
Always writing to /etc/apt/sources.list is stupid
because it makes tracking changes harder, so let's
try to move debian specifica into debian.list and
sipwise specifica to sipwise.list instead.
Victor Seva
Michael Prokop
Alexander Lutay
Kirill Solomko