Dependency-based boot

iti-asi

Member
Jul 14, 2009
52
0
6
València
www.iti.upv.es
Hi,

As you know, I'm quickly trying to move all our new servers to Debian squeeze. One of the last pending issues is to adapt the OpenVZ and PVE init scripts to the new policy, which basically means adding LSB init headers and not using just a symlink but do a real script install so it's not ignored.

The OpenVZ vzreboot script should be fixed in vzctl. See http://bugzilla.openvz.org/show_bug.cgi?id=1423.

I've done a pair of tests to fix the PVE side of the problem; that is, fixing ssh_gen_host_keys, and am encountering a weird problem when trying to install the script.
Code:
--- DAB.pm.orig    2010-09-06 12:09:50.000000000 +0200
+++ DAB.pm    2010-09-06 13:42:23.000000000 +0200
@@ -1158,9 +1158,9 @@
     my $rootdir = $self->vz_root_dir();
 
     my $base = basename ($script);
-    my $target = sprintf ("$rootdir/etc/rc${runlevel}.d/S%02d${base}", $prio);
+    my $target = "$rootdir/etc/init.d";
     $self->run_command ("install -m 0755 '$script' '$target'");
-    return $target;
+    $self->run_command ("update-rc.d $base start $prio $runlevel");
 }
 
 sub bootstrap {
@@ -1381,6 +1381,7 @@
     # reset password
     $self->ve_command ("usermod -L root");
 
+    # regenerate sshd host keys
     $self->install_init_script ($script_ssh_init, 2, 14);
 
     if ($mta eq 'postfix') {

--- ssh_gen_host_keys.orig    2010-09-06 12:11:10.000000000 +0200
+++ ssh_gen_host_keys    2010-09-06 12:53:23.000000000 +0200
@@ -1,4 +1,14 @@
 #!/bin/sh
+### BEGIN INIT INFO
+# Provides:          ssh_gen_host_keys
+# Required-Start:    $local_fs
+# Required-Stop:
+# X-Start-Before:    sshd
+# Default-Start:     2
+# Default-Stop:
+# Short-Description: Regenerate SSH keys
+# Description:       Regenerate container SSH keys for uniqueness.
+### END INIT INFO
 
 set -e
 
@@ -16,4 +26,5 @@
 rm -f /etc/ssh/ssh_host_dsa_key
 ssh-keygen -q -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
 
-rm -f $0
+rm -f /etc/init.d/ssh_gen_host_keys
+update-rc.d -f ssh_gen_host_keys remove

However, I'm stuck because dab bootstrap is failing on me, and I'm not sure why:
Code:
unpack: libgssapi-krb5-2
unpack: libkrb5-3
unpack: ssl-cert
unpack: libncursesw5
unpack: cpio
configure important packages
command 'update-rc.d ssh_gen_host_keys start 14 2' failed with exit code 1
command 'update-rc.d ssh_gen_host_keys start 14 2' failed with exit code 1
make: *** [all] Error 1

Can anyone lend me a pair of eyes to see what probably silly mistake is going here?
The alternative is to simply install the script and then add a symlink by hand, which would work for our really silly usecase, but I want to try this first.
 
Can anyone lend me a pair of eyes to see what probably silly mistake is going here?
The alternative is to simply install the script and then add a symlink by hand, which would work for our really silly usecase, but I want to try this first.

Why does it run ssh_gen_host_keys during DAB build? The rc policy forbids that? Will test tomorrow.
 
Why does it run ssh_gen_host_keys during DAB build? The rc policy forbids that? Will test tomorrow.

It does not run (or shouldn't) the script during build, but update-rc.d to install the appropriate symlink in /etc/rc2.d. That command works flawlessly if I vzctl enter 90000 and do it by hand. For some reason it fails at that point of the setup. Maybe one of the tools update-rc.d uses is diverted or disabled at that stage?
 
Maybe one of the tools update-rc.d uses is diverted or disabled at that stage?

Why do you want to change something that works into something that does not work? What is the advantage of using "update-rc.d"?
Or is it no longer feasible to simply install a symlink in /etc/rc2.d?
 
Last edited:
First, dab produce a detailed log file called 'logfile'. Just take a look at that file when something fails:

Code:
   update-rc.d: /etc/init.d/ssh_gen_host_keys: file does not exist
  command 'update-rc.d ssh_gen_host_keys start 14 2' failed with exit code 1

You execute 'update-rd.d' on the host. Instead you should run it inside the guest!

Code:
Index: DAB.pm
===================================================================
--- DAB.pm      (revision 5029)
+++ DAB.pm      (working copy)
@@ -1158,8 +1158,10 @@
     my $rootdir = $self->vz_root_dir();
 
     my $base = basename ($script);
-    my $target = sprintf ("$rootdir/etc/rc${runlevel}.d/S%02d${base}", $prio);
+    my $target = "$rootdir/etc/init.d/$base";
     $self->run_command ("install -m 0755 '$script' '$target'");
+    $self->ve_command ("update-rc.d $base start $prio $runlevel");
+
     return $target;
 }
 
First, dab produce a detailed log file called 'logfile'. Just take a look at that file when something fails:

Code:
   update-rc.d: /etc/init.d/ssh_gen_host_keys: file does not exist
  command 'update-rc.d ssh_gen_host_keys start 14 2' failed with exit code 1
You execute 'update-rd.d' on the host. Instead you should run it inside the guest!
Wow, that was really silly! Thanks for the pointer, I was pretty sure it was something simple. ;)
I hope you can integrate this in a new dab version soon!
 
Wow, that was really silly! Thanks for the pointer, I was pretty sure it was something simple. ;)
I hope you can integrate this in a new dab version soon!

just waiting for the 'scripts/mysql_randomp' patch - would you mind to provide/test it?
 
just waiting for the 'scripts/mysql_randomp' patch - would you mind to provide/test it?

I'm not sure if I fully understand what's going on with MySQL. Here's a patch for the script, but not for DAB.pm.

Code:
--- mysql_randompw.orig    2010-09-08 13:24:56.000000000 +0200
+++ mysql_randompw    2010-09-08 13:41:44.000000000 +0200
@@ -1,4 +1,14 @@
 #!/bin/sh
+### BEGIN INIT INFO
+# Provides:          mysql_randompw
+# Required-Start:    $local_fs
+# Required-Stop:
+# X-Start-Before:    mysql
+# Default-Start:     2
+# Default-Stop:
+# Short-Description: Generate random MySQL root password
+# Description:       Generate and set a random MySQL root password
+### END INIT INFO
 
 set -e
 
@@ -23,4 +33,5 @@
 
 chmod 0600 /root/.my.cnf
 
-rm -f $0
+rm -f /etc/init.d/mysql_randompw
+update-rc.d -f mysql_randompw remove
If this needs to be run *after* mysql is started, the trivial change is to use X-Start-After.

DAB.pm needs a change I'm not sure about:
Code:
    my $rpwscript = glob ("$rootdir/etc/rc2.d/S*mysql_randompw");
If you can take care of those two details, I think that's enough.
 
Hi,

As you know, I'm quickly trying to move all our new servers to Debian squeeze. One of the last pending issues is to adapt the OpenVZ and PVE init scripts to the new policy, which basically means adding LSB init headers and not using just a symlink but do a real script install so it's not ignored.

The OpenVZ vzreboot script should be fixed in vzctl. See http://bugzilla.openvz.org/show_bug.cgi?id=1423.

Dietmar, browsing the Debian changelog for squeeze's vzctl, I see Ola seems to have fixed this in the official Debian package:
Code:
   * Backported solution from upstream to solve the problem with vz
     container reboot and insserv. Closes: [URL="http://bugs.debian.org/576227"]#576227[/URL]. This solution is provided
     by a series of patches. A new vzeventd function is introduced and removes
     the need for cron jobs.

Does it make sense to include these changes in the PVE package in order to fix the remaining insserv issue? Thanks in advance.
 
Oops. You are right. For now, either we stick with a non-working vzreboot, or do a bit of hackery in vzctl: instead of writing that broken init script, a "correct" header can be written and a symlink installed for compatibility with non-insserv installs. This way, it'd work for both worlds.

My C skills are *really* horrible, but we can try to give it a whirl here when I get really fed up of the insserv warning.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!