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
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.
Michael Prokop
Victor Seva
Alexander Lutay