https://sourceforge.net/p/kluster/wiki/CustomizingImage2/Recent changes to CustomizingImage2enSat, 06 Jun 2015 04:54:02 -0000https://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v31 +++ v32 @@ -140,12 +140,21 @@ This should not produce any output. It sets up soft links to the init scripts in /etc/init.d/, from the directories /etc/rcN.d for different runlevels. The directory for runlevel 4 (normal startup) should look as follows; this lets you know what order things will be started up in: # ls /etc/rc4.d/ - README S02cloud-init S03cloud-config S14autofs S18gridengine-exec - S01bootlogs S02dbus S03ssh S14nfs-kernel-server S19cloud-final - S01cloud-init-local S02exim4 S04kluster-set-hostname S15cron S19kluster-mktemp - S01motd S02mem-killer S12rpcbind S15gridengine-master S19rc.local - S01rsyslog S02ntp S13nfs-common S16kluster-configure-queue S19rmnologin - S01sudo S02rsync S13nis S17kluster-misc-tasks + README S12rpcbind + S01bootlogs S13nfs-common + S01cloud-init-local S13nis + S01motd S14autofs + S01rsyslog S14nfs-kernel-server + S01sudo S15cron + S02cloud-init S15gridengine-master + S02dbus S16kluster-configure-queue + S02exim4 S17kluster-misc-tasks + S02mem-killer S18gridengine-exec + S02ntp S19cloud-final + S02rsync S19kluster-mktemp + S03cloud-config S19rc.local + S03ssh S19rmnologin + S04kluster-set-hostname (Note: the `insserv` command uses the "init info" in the comments at the top of the scripts in /etc/init.d to work out the dependencies between init jobs, which determines the order). </pre> </div>Carl PupaSat, 06 Jun 2015 04:54:02 -0000https://sourceforge.netd78fc2de42cb3a43a0d5c7400ef331d85ff295e1https://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v30 +++ v31 @@ -19,6 +19,7 @@ # ec2kill i-7877a019 INSTANCE i-7877a019 stopped terminated + Further configuration... ------------------------------- @@ -67,6 +68,7 @@ sudo rsync pkg-config gdb iftop libxml-simple-perl subversion \ libatlas3-base g++ patch bzip2 + Enable ability to ssh as root ----------------------------- @@ -117,7 +119,7 @@ /usr/lib/yp/ypinit -m -The `ypinit` command requires user interaction; you have to press ctrl-D and then y. In previous versions of Debian there were some harmless warnings about `failed to send 'clear' to local ypserv: RPC: Program not registered`. Next, run `service nis restart`: +The `ypinit` command requires user interaction; you have to press ctrl-D and then y. There will be some harmless warnings about `failed to send 'clear' to local ypserv: RPC: Program not registered`. Next, run `service nis restart`: # service nis restart Stopping NIS services: ypbind ypserv ypppasswdd ypxfrd. </pre> </div>Carl PupaSat, 06 Jun 2015 04:47:39 -0000https://sourceforge.net2683d8c819cc6c96812d7ff615903bd4ecdee1adhttps://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v29 +++ v30 @@ -19,6 +19,9 @@ # ec2kill i-7877a019 INSTANCE i-7877a019 stopped terminated + +Further configuration... +------------------------------- OK, now we're ready to continue configuring the image. On the new instance, type: @@ -94,6 +97,7 @@ ssh -i ~/.ssh/mycluster.pem root@ec2-54-235-5-54.compute-1.amazonaws.com + Push scripts from local machine to image ---------------------------------------- @@ -102,8 +106,9 @@ bin/push-configs.sh ~/.ssh/mycluster.pem ec2-54-234-152-143.compute-1.amazonaws.com \ `cat scripts/root/config_files` -Finishing up... ---------------- + +Complete service setup +------------------------ We now have to finish a few things before creating the image. First we have to initialize the NIS database. Do as follows **on the instance**: @@ -140,7 +145,9 @@ S01rsyslog S02ntp S13nfs-common S16kluster-configure-queue S19rmnologin S01sudo S02rsync S13nis S17kluster-misc-tasks -(Note: the `insserv` command uses the "init info" in the comments at the top of the scripts in /etc/init.d to work out the dependencies between init jobs, which determines the order). At this point we can check that a few things are working before we shut down and make the image. First we check that NIS (which used to be called Yellow Pages/YP) is working: +(Note: the `insserv` command uses the "init info" in the comments at the top of the scripts in /etc/init.d to work out the dependencies between init jobs, which determines the order). + +At this point we can check that a few things are working before we shut down and make the image. First we check that NIS (which used to be called Yellow Pages/YP) is working: # ypcat -k auto.master /export auto.export -rw,nfsvers=3,intr,rsize=8192,wsize=8192,timeo=1000,retrans=5,bg,retry=5,proto=tcp,actimeo=10 @@ -175,6 +182,9 @@ These commands set various configuration parameters of the queue, to values that I generally work with and that should work well for [Kaldi](kaldi.sf.net) system building. If you are going to administer a GridEngine cluster you should probably become familiar with GridEngine administration. Commands and associated options that you will likely use a lot include qstat, qhost -q, qconf -mq, qconf -dh, qconf -dh, qconf -ae, qconf -de, qconf -mc, qconf -mconf. Type `man qconf` for more information. +Create image +------------ + Now we will create an image from the instance. From your local machine, stop the image: # ec2stop i-b7a975d8 </pre> </div>Carl PupaFri, 05 Jun 2015 05:37:26 -0000https://sourceforge.net2c9a19a05cb9fde34b008601976b11b9fb830b2dhttps://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v28 +++ v29 @@ -64,6 +64,9 @@ sudo rsync pkg-config gdb iftop libxml-simple-perl subversion \ libatlas3-base g++ patch bzip2 +Enable ability to ssh as root +----------------------------- + Next we need to set up one more thing so that we can ssh as root. On startup, Debian 7 inserts a command into /root/.ssh/authorized_keys entries which disables root login. # cat /root/.ssh/authorized_keys @@ -73,7 +76,7 @@ no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa &lt;snip long="" rsa="" entry=""&gt; -This could be done manually, or via a on-line script such as: +This could be done manually, or via the commandline: sed -i 's/,command=.*\bssh-rsa\b/ ssh-rsa/g' /root/.ssh/authorized_keys @@ -91,10 +94,16 @@ ssh -i ~/.ssh/mycluster.pem root@ec2-54-235-5-54.compute-1.amazonaws.com +Push scripts from local machine to image +---------------------------------------- + Now you are ready to transfer a large number of config files and scripts from your "kluster" distribution on the local machine, to the instance. If you want to see what kinds of configuration changes are taking place, the following command may be useful. Run this **from your local machine**, in the kluster directory, and use the internet name of your actual instance: bin/push-configs.sh ~/.ssh/mycluster.pem ec2-54-234-152-143.compute-1.amazonaws.com \ `cat scripts/root/config_files` + +Finishing up... +--------------- We now have to finish a few things before creating the image. First we have to initialize the NIS database. Do as follows **on the instance**: </pre> </div>Carl PupaFri, 05 Jun 2015 05:32:05 -0000https://sourceforge.netb16c9922c24f9725e2d03d9348052bfee2d910bchttps://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v27 +++ v28 @@ -124,12 +124,12 @@ This should not produce any output. It sets up soft links to the init scripts in /etc/init.d/, from the directories /etc/rcN.d for different runlevels. The directory for runlevel 4 (normal startup) should look as follows; this lets you know what order things will be started up in: # ls /etc/rc4.d/ - README S02cloud-init S03ssh S15cron - S01bootlogs S02dbus S12rpcbind S18gridengine-exec - S01cloud-init-local S02exim4 S13nfs-common S19cloud-final - S01motd S02ntp S13nis S19rc.local - S01rsyslog S02rsync S14autofs S19rmnologin - S01sudo S03cloud-config S14nfs-kernel-server + README S02cloud-init S03cloud-config S14autofs S18gridengine-exec + S01bootlogs S02dbus S03ssh S14nfs-kernel-server S19cloud-final + S01cloud-init-local S02exim4 S04kluster-set-hostname S15cron S19kluster-mktemp + S01motd S02mem-killer S12rpcbind S15gridengine-master S19rc.local + S01rsyslog S02ntp S13nfs-common S16kluster-configure-queue S19rmnologin + S01sudo S02rsync S13nis S17kluster-misc-tasks (Note: the `insserv` command uses the "init info" in the comments at the top of the scripts in /etc/init.d to work out the dependencies between init jobs, which determines the order). At this point we can check that a few things are working before we shut down and make the image. First we check that NIS (which used to be called Yellow Pages/YP) is working: </pre> </div>Carl PupaFri, 05 Jun 2015 04:20:58 -0000https://sourceforge.net924ac0346e06f42507b7bb2b54b6704a2a414d3bhttps://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v26 +++ v27 @@ -69,7 +69,7 @@ # cat /root/.ssh/authorized_keys no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"admin\" rather than the user \"root\".';echo;sleep 10" ssh-rsa &lt;snip long="" rsa="" entry=""&gt; -We need to remove the ",command=" and everything in quotes, so that it looks like: +We need to remove the **,command="echo 'Please login as the user \"admin\" rather than the user \"root\".';echo;sleep 10"** part, so that it looks like: no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa &lt;snip long="" rsa="" entry=""&gt; </pre> </div>Carl PupaFri, 05 Jun 2015 03:48:55 -0000https://sourceforge.net27f1f0c2d10e2aa215c8e8cd5d365a56f65f0363https://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v25 +++ v26 @@ -9,7 +9,7 @@ ec2tag i-b7a975d8 --tag Name=customizing_phase_2 -Type `ec2din i-b7a975d8` (but use your new instance-id) to get the internet address (FQDN) of the instance, and ssh to it: something like, +Type `ec2din i-b7a975d8` (but use your new instance-id) to get the internet address (FQDN) of the instance, and ssh into it as the admin user (we cannot yet login as root user): something like, ssh -i ~/.ssh/mycluster.pem admin@ec2-54-234-152-143.compute-1.amazonaws.com @@ -66,18 +66,18 @@ Next we need to set up one more thing so that we can ssh as root. On startup, Debian 7 inserts a command into /root/.ssh/authorized_keys entries which disables root login. - root@master:~# cat .ssh/authorized_keys + # cat /root/.ssh/authorized_keys no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"admin\" rather than the user \"root\".';echo;sleep 10" ssh-rsa &lt;snip long="" rsa="" entry=""&gt; We need to remove the ",command=" and everything in quotes, so that it looks like: no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa &lt;snip long="" rsa="" entry=""&gt; -This could be done manually, or via a on-line script: +This could be done manually, or via a on-line script such as: sed -i 's/,command=.*\bssh-rsa\b/ ssh-rsa/g' /root/.ssh/authorized_keys -Now do: +Edit /root/.ssh/authorized_keys, and then do: service ssh restart @@ -85,13 +85,13 @@ ssh master -just to check that it can ssh to itself without a password. You should get a prompt. Just type "exit" to go back to your original session. If there is an error you'll have to figure out what went wrong. +just to verify that we can still ssh to ourself as root without a password. You should get a prompt. Just type "exit" to go back to your original session. If there is an error you'll have to figure out what went wrong. -and, from a separate window on your local machine, verify that you can now ssh to the instance as root: something like +Then, from a separate window on your local machine, verify that you can now ssh to the instance as root: something like ssh -i ~/.ssh/mycluster.pem root@ec2-54-235-5-54.compute-1.amazonaws.com -Next we will be transferring a large number of config files and scripts from your "kluster" distribution on the local machine, to the instance. If you want to see what kinds of configuration changes are taking place, the following command may be useful. Run this **from your local machine**, in the kluster directory, and use the internet name of your actual instance: +Now you are ready to transfer a large number of config files and scripts from your "kluster" distribution on the local machine, to the instance. If you want to see what kinds of configuration changes are taking place, the following command may be useful. Run this **from your local machine**, in the kluster directory, and use the internet name of your actual instance: bin/push-configs.sh ~/.ssh/mycluster.pem ec2-54-234-152-143.compute-1.amazonaws.com \ `cat scripts/root/config_files` </pre> </div>Carl PupaFri, 05 Jun 2015 02:46:33 -0000https://sourceforge.netb2a0f316c3264cb1bd5b7ecf766d3cb3f6ad6127https://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v24 +++ v25 @@ -2,7 +2,7 @@ We'll assume that the AMI you just created is now ready. Execute the command below, replacing the AMI-ID with the one you just made: - ec2run ami-8eaf37e7 -g mycluster -k mycluster -z us-east-1c -t m1.large \ + ec2run ami-8eaf37e7 -g mycluster -k mycluster -z us-east-1c -t c3.large \ -b "/dev/xvdb=ephemeral0" -b "/dev/xvdc=ephemeral1" Here, the `-b` option makes it attach the local storage `ephemeral0` of the machine as device /dev/xvdb. When we create an image from this machine, this specification becomes part of the AMI and it will happen automatically. The command above will print out the instance-id (i-something) of the instance, along with other information. It is good practice to tag the instance with a meaningful name: </pre> </div>Carl PupaFri, 05 Jun 2015 02:40:22 -0000https://sourceforge.net1f1371f151c0ca38c09bb4cca988f8eeec871823https://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v23 +++ v24 @@ -124,11 +124,10 @@ This should not produce any output. It sets up soft links to the init scripts in /etc/init.d/, from the directories /etc/rcN.d for different runlevels. The directory for runlevel 4 (normal startup) should look as follows; this lets you know what order things will be started up in: # ls /etc/rc4.d/ - root@master:~/queue# ls /etc/rc2.d README S02cloud-init S03ssh S15cron S01bootlogs S02dbus S12rpcbind S18gridengine-exec S01cloud-init-local S02exim4 S13nfs-common S19cloud-final - S01motd S02ntp S13nis S19rc.local + S01motd S02ntp S13nis S19rc.local S01rsyslog S02rsync S14autofs S19rmnologin S01sudo S03cloud-config S14nfs-kernel-server </pre> </div>Carl PupaFri, 05 Jun 2015 02:38:00 -0000https://sourceforge.net5036e230afdf9c59f72712d3192011e778890cedhttps://sourceforge.net/p/kluster/wiki/CustomizingImage2/<div class="markdown_content"><pre>--- v22 +++ v23 @@ -125,12 +125,12 @@ # ls /etc/rc4.d/ root@master:~/queue# ls /etc/rc2.d - README S02cloud-init S03ssh S15cron + README S02cloud-init S03ssh S15cron S01bootlogs S02dbus S12rpcbind S18gridengine-exec S01cloud-init-local S02exim4 S13nfs-common S19cloud-final - S01motd S02ntp S13nis S19rc.local + S01motd S02ntp S13nis S19rc.local S01rsyslog S02rsync S14autofs S19rmnologin - S01sudo S03cloud-config S14nfs-kernel-server + S01sudo S03cloud-config S14nfs-kernel-server (Note: the `insserv` command uses the "init info" in the comments at the top of the scripts in /etc/init.d to work out the dependencies between init jobs, which determines the order). At this point we can check that a few things are working before we shut down and make the image. First we check that NIS (which used to be called Yellow Pages/YP) is working: </pre> </div>Carl PupaFri, 05 Jun 2015 02:36:59 -0000https://sourceforge.net6dff4607ca009ec08a9e65ff7e61c9ec81f31052