Month: July 2017

Backup Disk Images to Another Ubuntu Box

I wanted to backup my mining rig disk images to another machine with the hopes that I could easily load the images to extract files. The following works well for home directories that are not encrypted. For directories that are encrypted, I am currently copying files out selectively – not sure if there is a better way. But, what follows works for copying unencrypted disk images over SSH and then mounting them on another machine.

Determine the path for the filesystem you want to backup:

$ df

On the machine you want to backup:

$ sudo dd if=path/from/df | gzip -c --fast | ssh user@ip 'dd of=~/path/to/backup.dd.gz' &

Then to mount the image on the receiver:

$ gunzip -c backup.dd.gz >backup.dd
$ sudo mkdir /mnt/disk_image
$ sudo losetup --partscan --find --show backup.dd
$ sudo mount /dev/loop0 /mnt/disk_image

To unmount after:

$ losetup -d /dev/loop0

References 1 2 3 4

Backup Ethereum Wallet

This is how I backup my Ethereum root folder (which includes the wallet) from one Ubuntu box to another.

This command is run from the perspective of the receiver-of-the-backup (i.e. where you want the backup to reside).

$ scp -r user@ip:~/.ethereum/ ~/Desktop/backup/

In your backup directory, to make the folder unhidden do this:

$ mv .ethereum ethereum

SSH – Adding Public Key Authentication for Ubuntu 16.04 LTS

  1. Check if the public key already exist on your local machine. 
    $ locate id_rsa

    If they do, go to the step the copies the public key to your destination machine.

  2. If the public key doesn’t already exist, execute 
    $ ssh-keygen

    For my purposes, I hit -enter- then -enter- again. It shows a pretty picture. Now we’ve got public and private keys.

  3. Now, it is time to deploy the public key to the destination servers of interest. 
    $ ssh-copy-id userX@server1_ip
$ ssh-copy-id userY@server2_ip

    If your ssh-copy-id does not work (like my Mac), then you have to manually cut and paste the contents of the local ~/.ssh/id_rsa.pub to the destination’s ~/.ssh/authorized_keys.

  4. Then, restrict access for all the authorized_keys files on all your servers. 
    $ chmod 600 ~/.ssh/authorized_keys

    Tip: On one of my machines the owner of the authorized_keys was root and because of that, the public key authentication didn’t work and I was entering passwords. Had to chown it the desired user. This link pointed me in the right direction.

  5. Further lock things down by disabling password authentication on your destination ssh server. 
    $ sudo nano /etc/ssh/sshd_config

    and then make sure this line exists

    PasswordAuthentication no

    To lock down at certain times of the day, check out this out.

  6. If you are a home internet user, it is likely that your IP address may change. Luckily, there are services around that let you publish your IP address to a known server. These servers are called dynamic DNS hosting. For my purposes I went with Duck DNS. It is simple to sign-up with and they provide detailed instructions under their “install” tab.

Steps condensed from this reference.

Steps for Desktop Sharing on Ubuntu 16.04 LTS

In order to view the desktop of another Ubuntu 16.04 LTS machine follow these steps.  I performed these actions to make my life easier on my home cryptocoin mining network – this is not the most secure method. But, it works and I can get to my machines.  I perform these steps right after building a new box.

Unencrypted Home Directory Pre-requisite: If you want to have your remote machine auto-login so that you can remote into it whenever you need…you will have to unencrypted your home directory if it is encrypted. Follow this link and steps (PDF Version). Pre-pre-requisite: If you do indeed need to perform these unencryption steps, you will need to know how to create another sudo user (link PDF Version)

If you intend on running your “remote” machine as headless (i.e. no monitor) you may need to follow my steps to fake the box out to think it has a monitor connected. If you have a rig that you see runs XOrg at high CPU and you aren’t mining, you may be suffering from a headless server that needs to be tricked!

From your “viewing” machine:

  1. ssh to your “sharing” machine
  2. See if vino-server is installed 
    $ locate vino-server
  3. If the above comes back blank then: 
    $ sudo apt-get install vino
  4. Now we have to configure the vino-server 
    $ export DISPLAY=:0.0
$ dbus-launch gsettings set org.gnome.Vino enabled true
$ dbus-launch gsettings set org.gnome.Vino prompt-enabled false
$ dbus-launch gsettings set org.gnome.Vino authentication-methods "['vnc']"
$ dbus-launch gsettings set org.gnome.Vino vnc-password "$(echo -n "YOU-ENTER-A-PASSWORD-FOR-DESKTOP-SHARING-HERE" | base64)"
$ dbus-launch gsettings set org.gnome.Vino require-encryption true

    Notes:

    • The first bolded above is the area you need to enter the password you will enter from the client machine
    • Regarding the bold field under encryption: if you are connecting from another Ubuntu machine leave it as “true.” If you are connecting from a Mac…then switch it to “false.” On macs use the program called “screen sharing” that ships with OS X (hit command+space to bring up spotlight and search for “screen sharing”).
    • The dubs-launch command is needed because we are executing this remotely from shell prompt
    • The first command related to the DISPLAY variable needs some extended discussion. First, to see what value it holds you can run “echo $DISPLAY”. The format of the display variable is hostname:display.screen (where the hostname is usually omitted, both display and screen start at 0, and if screen is not provided it defaults to 0). Now in this context, the definition of “display” is nuanced. It conceptually means a collection of monitors that share one set of input devices (e.g. mouse and keyboard). “screen” just means the monitor number for the “display” of interest. Ref
  5. This is how you run it 
    $ /usr/lib/vino/vino-server

    Did it give you an error…something like “Could not connect: Connection refused Cannot open display:”? If so continue to the next step.

  6. In order to start vino-server remote machine must be showing some sort of graphical interface. The remote machine cannot be stuck on the login screen. To work around this we need to configure the remote machine to automatically login. If you do happen to try running /usr/lib/vino/vino-server without doing this you will receive
  7. To autologin: 
    $ sudo mkdir /etc/lightdm/lightdm.conf.d
$ sudo nano /etc/lightdm/lightdm.conf.d/50-myconfig.conf
    [SeatDefaults]
autologin-user=USERNAME

    Reference

  8. Let’s configure vino-server to autostart. I tried a couple of different methods, and the following was the easiest and cleanest. Doing this at the command line will actually populate entries on the “Application Autostart” tab of the “Session and Startup” application in the GUI. 
    $ mkdir ~/.config/autostart
$ cd ~/.config/autostart
$ nano Vino.desktop
    [Desktop Entry]
Name=Vino Server
Exec=/usr/lib/vino/vino-server
Type=Application

    In my case I have a Claymore95 miner, and I want it to autostart too!

    $ nano Claymore.desktop

    Now, the following shows what the GUI will populate

    [Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=Claymore
Comment=mining
Exec=/bin/bash -c "sleep 10 && cd /usr/local/claymore95/ && nohup ./mine.sh &"
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false

    A helpful reference for the autostart step

  9. Let’s restart the server machine! 
    $ sudo shutdown -r now
  10. On the client machine, you need to download the remote viewer. From the Start menu, run the Software application. Within, download the “Remote Desktop Viewer.”
  11. Now, at this point the server should be restarted. You can now run the “Remote Desktop Viewer” to connect. You should get prompted for the password you established above, and you should see the shared remote desktop!