Moving a SmartMachine between Compute Nodes

Moving a SmartMachine between Compute Nodes

This page shows you how you can migrate one SmartMachine from one compute node to another. This is a manual procedure, and there are some limitations:

  • Your head node software must be Imbe (11 June 2011) or later.
    The source and destination compute nodes must be in the same subnet.
  • You must be able to log in to the global zone of the source compute node.
  • You must be able to access the destination compute node from the source compute node using SSH.

In this example, we’re migrating the zone named z1 from the source compute node. Both nodes are in the Admin subnet. The destination compute node’s IP address is, and its UUID is 564d2a09-3821-893f-ab2a-9fb225325c53. The MAPI zone has IP address

On the source compute node
Log in to the destination compute node to confirm that you can perform remote operations on it. You only need to do the step once per destination node.

ssh root@

You should see a prompt similar to the following:

The authenticity of host ' (' can't be established.
RSA key fingerprint is 05:84:39:47:2a:c2:c4:9e:42:dd:2c:4e:3a:5b:3f:53.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.

Enter the root password to confirm that you can access the node, then logout.

Halt the zone you want to move and create its ZFS snapshot.

zoneadm -z z1 halt
zfs snapshot zones/z1@migration

Send the zone’s file system to the destination. Whenever possible use the Admin network for sending the snapshot. Second best is the External network. The public network is last.

zfs send zones/z1@migration | ssh root@ zfs recv -d zones

You will be prompted for the root password on

Destroy the snapshot on the source compute node.

zfs destroy zones/z1@migration

Copy the zone definition to the destination.

scp /etc/zones/z1.xml root@

You will be prompted for the root password on

Disable the zone from running again on the source compute node.

zonecfg -z z1 set autoboot=false

Once the zone has been confirmed to be running properly
on the destination, you can remove the zone from the source.

zoneadm -z z1 uninstall -F
zonecfg -z z1 delete -F

Do not leave both the old zone and the new zone running at the same time.
On the destination compute node
Get rid of the ZFS snapshot.

zfs destroy zones/z1@migration

Make zone z1 known to the system.

zonecfg -z z1 create -X
zoneadm -z z1 attach -F

Boot the zone.

zoneadm -z z1 boot

Check that the migration went well. Make sure that svcs and the network are working.

zlogin z1
netstat -rn
svcs -xv

Update MAPI with zone’s new server
Finally, you need to let MAPI know that you’ve moved the zone from one compute node to another.

headnode# sdc-mapi /zones/z1/mark_as_migrated \
         -X POST \
         -d 'server_uuid=564d2a09-3821-893f-ab2a-9fb225325c53'Unix

SSH authentication refused – authorized_keys

If you have a problem to login per ssh and key in the server you must check the auth.log file to see more detail.


Authentication refused: bad ownership or modes for directory /home/user/.ssh

When you see this message you have a problem with the permission of .ssh/authorized_keys

chmod 600 .ssh/authorized_keys
chmod 700 .ssh/

By adding

StrictModes off

to your sshd_config file you can also fix the problem, but thats not a good idea. Fixing the permission is the best way.

Nginx SSL Labs A+

Nginx SSL Labs A+

To get a high secure SSL installation on Nginx you should use the following config. With this settings you also get on A+.

SSL Labs A+
SSL Labs A+

It is important to create the Forward Secrecy & Diffie Hellman Ephemeral Parameters.

You can create the dhparm.pem with openssl

openssl dhparam -out www_safematix_com_dhparam.pem 4096
ssl on;
ssl_certificate /etc/nginx/ssl/safematix/www_safematix_com.crt;
ssl_certificate_key /etc/nginx/ssl/safematix/www_safematix_com.key;
ssl_trusted_certificate /etc/nginx/ssl/safematix/ca.pem;

ssl_dhparam /etc/nginx/ssl/safematix/www_safematix_com_dhparam.pem;

ssl_session_timeout 5m;
ssl_session_cache shared:SSL:10m;

ssl_stapling on;
ssl_stapling_verify on;
resolver valid=300s;
resolver_timeout 10s;

add_header Strict-Transport-Security max-age=63072000;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # not possible to do exclusive
add_header Strict-Transport-Security max-age=15768000; # six months
# use this only if all subdomains support HTTPS!
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains";

Migration Mercurial to git

Migration mercurial to git

Clone the old repo

hg clone mercurial-repo

create a file name my-filemap with

exclude path/to/.git

Convert the old repo to a new Mercurial repo without git folders

hg convert --filemap my-filemap mercurial-repo/ new_mercurial-repo

create the new git repo

mkdir git
cd git
git init

Convert the Mercurial to git

/usr/bin/hg-fast-export -r ../new_mercurial-repo

Check the new git repo

git fsck

If all is okay

git checkout HEAD
git remote add origin
git push -u origin master

Migrate git repository to new server

Migrate git repository to new server

Clone the old repo

 git clone git@OLD_SERVER:GROUP/PROJECT.git

Look for the remote server in you repo

git remote -v
origin git@OLD_SERVER:GROUP/PROJECT.git (fetch)
origin git@OLD_SERVER:GROUP/PROJECT.git (push)

Remove the old server from list

git remote rm origin

Add new server and push the repo

git remote add origin git@NEW_SERVER:GROUP/PROJECT.git
git push -u origin master

If you like to copy the tags

git push origin --tags -f