scp foo user@host:~/bar
# To copy a folder use the prefix -R foo/, like this
scp -R foo/ user@host:~/

ssh -l user host -D 8080

ssh -l user host -L 8080:localhost:80

Host foo
        User root
        HostName host
        IdentityFile ~/.ssh/otherkey
        Compression yes
        CompressionLevel 9
        KeepAlive Yes
Host bar
        User foo
        HostName host

First, create the file

sudo nano /usr/bin/ssh-copy-id

Insert bash-script. Optionally you can get the script another OpenSSH installation, like Debian or Ubuntu. See “cat /usr/bin/ssh-copy-id”.

#!/bin/sh

# Shell script to install your public key on a remote machine
# Takes the remote machine name as an argument.
# Obviously, the remote machine must accept password authentication,
# or one of the other keys in your ssh-agent, for this to work.

ID_FILE="${HOME}/.ssh/id_rsa.pub"

if [ "-i" = "$1" ]; then
  shift
  # check if we have 2 parameters left, if so the first is the new ID file
  if [ -n "$2" ]; then
    if expr "$1" : ".*\.pub" > /dev/null ; then
      ID_FILE="$1"
    else
      ID_FILE="$1.pub"
    fi
    shift         # and this should leave $1 as the target name
  fi
else
  if [ x$SSH_AUTH_SOCK != x ] && ssh-add -L >/dev/null 2>&1; then
    GET_ID="$GET_ID ssh-add -L"
  fi
fi

if [ -z "`eval $GET_ID`" ] && [ -r "${ID_FILE}" ] ; then
  GET_ID="cat ${ID_FILE}"
fi

if [ -z "`eval $GET_ID`" ]; then
  echo "$0: ERROR: No identities found" >&2
  exit 1
fi

if [ "$#" -lt 1 ] || [ "$1" = "-h" ] || [ "$1" = "--help" ]; then
  echo "Usage: $0 [-i [identity_file]] [user@]machine" >&2
  exit 1
fi

{ eval "$GET_ID" ; } | ssh ${1%:} "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1

cat <<EOF
Now try logging into the machine, with "ssh '${1%:}'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

EOF

Then make it executable by the system.

chmod +x /usr/bin/ssh-copy-id

So far I’ve noticed that the changes are small and often very discrete. The following picture is from a Norwegian chain letter that was on Facebook, posted by two of my friends. So it’s safe to say that the origin of this message is from more or less the same source, yet, only a few hops later, the message has evolved. The essential meaning stays the same, but they changed one little word.

When will this madness end? How will spam filters cope? Should we be alarmed? I’ve already equipped my tinfoil hat and will continue mye search for what i believe to be NBE’s.

Exhibit 1:

First we need to enable some modules:

a2enmod rewrite vhost_alias
/etc/init.d/apache2 restart

Next up we do some rewrite magic, you need to change some paths and domains to reflect your setup, personally I just use some search and replace in nano to reflect whatever domain and site I’m setting up.

<VirtualHost *:80>
ServerName eksempel.no
ServerAlias *.eksempel.no #wildcard catch all
VirtualDocumentRoot /var/www/%1
UseCanonicalName Off
IndexOptions FancyIndexing
### Use mod_rewrite to direct eksempel.no to www.eksempel.no
RewriteEngine On
RewriteCond %{HTTP_HOST} ^eksempel.no
RewriteRule (.*) http://www.%{HTTP_HOST}$1 [R=301,L]
### Logging
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog /var/log/apache2/access_log_eksempel combined
<Directory /var/www>
AllowOverride None
</Directory>
</VirtualHost>

You must also restart Apache2 for your changes to apply.

/etc/init.d/apache2 restart

First we need to download and configure a yum-repo (1):

wget http://download.fedora.redhat.com/pub/epel/5/$(uname -i)/epel-release-5-4.noarch.rpm
rpm -hiv epel-release*.rpm
sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo

Install nrpe and nagios-plugins via yum and configure it to start on boot:

yum install --enablerepo=epel nagios-plugins nrpe
chkconfig nrpe on

Configure iptables to accept connections on 5666, the default nrpe-server port. Insert following line before the first -REJECT in /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT

Restart nrpe-server and iptables:

/etc/init.d/nrpe restart
/etc/init.d/iptables restart

That’s it. Configure nrpe as you’d normally would, making sure that you’ve edited allowed_hosts to accept connections from your Nagios-server.

Refrences:
(1) http://www.cmdln.org/2010/03/04/installing-nrpe-on-xenserver/

To access the ArcHTTP web interface you can tunnel your own connection inn via Socket 5 and configure whatever you needed (… to not mess with!) as localhost. When you are done you terminate the connection congratulate your self on a job well done.

ssh -l root host -D local_port

You might have to do small adjustments to stuff like users and parent directory. In this guide i use /root/ as parent directory for most actions, and all commands should work then.

Upgrading and Installing

It’s important that you do this on your target server and the server you are backuping, or else rdiff-backup will not be able to use ssh as it starts an rdiff-server on your target machine.

apt-get update
apt-get install rdiff-backup

Setting up SSH with keys

After installing rdiff we need to generate ssh-keys so that you can have automated rdiff-backups. I’ll only cover this briefly, but if you are unsure try to consult another guide i made about setting up key-based ssh authentication.

ssh-keygen
scp .ssh/id_rsa user@host:.ssh/id_rsa

This generates the keys you need and send them to the appropriate user on your remote machine for storing backups. If you are setting up more servers to use the same backup location copy id_rsa.pub over to them.

Using rdiff-backup

rdiff-backup -v5 –print-statistics /local-dir user@host::/remote-dir
rdiff-backup –remove-older-than 2W user@host::/remote-dir

Now we have created the first and initial backup, this might take some time, depending on your connection speed, disks and CPU. You should be able to watch what’s stores since we issued the -v5 comand (verbos 5).

Automating it

echo “#!/bin/sh” >> rdiff-backup.sh
echo “rdiff-backup -v5 –print-statistics /local-dir user@host::/remote-dir” >> rdiff-backup.sh
echo “rdiff-backup –remove-older-than 2W user@host::/remote-dir” >> rdiff-backup.sh

Running it

crontab -e

And insert the following line

* 0 * * * /root/rdiff-backup.sh

Save it! Now you can just sit back and relax and let ‘em backups flow, each night at twelve o’ clock.

Restoring

Maybe the most boring part but also the most important part, restoring. When you restore with rdiff-backup you can restore to any date you want, as long as it’s still being kept. In this guide we used 2W, or two weeks, so we should be able to restore a file 14 days back. Nifty!

rdiff-backup -r 14D user@host::/remote-dir/file /local-dir/file

This will restore the 14 days old file (-r 14D) of “file” to “/local-dir/file”. Pretty nifty, ey? If you are doing disaster recovery you can also recover an entire directory.

Final words

Do some simple tests, like backing up and restoring. This way you don’t get caught with your pants down when you actually need to restore something, and you ensure that backups actually are working – as this guide is not fully tested nor foolproof.

The disc can’t be burned; it might be incompatible with this disc drive. Please try a different brand of disc, or try burning at a slower speed.

you are probably in luck. It’s does not seem to be some sort of firmware error or anything wrong with the disk you are using. It’s simply the SuperDrives laser that has gotten dusty and needs cleaning. Simple find a creditcard and a t-shirt with long threaded weaving. Use the creditcard to hold the cloth wrapped around and insert it into the SuperDrive and carefully move it back and forth whilst applying a little force downwards. The optical sensor should be on the left side, but I cleaned both sides.

Note, if you are within warranty you should not do this at home. I guess mighty Steve would void your ass back to outer space if he ever saw you doing it… For some pictures of the madness, head over to PicasaWeb.

To install Chome To Phone you need to head over to Googles project server, as this is very beta at the moment.  Download and install the plugin for your Chrome browser and then open <your favorite barcode scanner> and scan the 2d-barcode for the Android App. To be able to install this app you need to setup your phone to accept applications from unknown sources under Settings -> Applications.

The Application requires that you run the latest version of Android, Froyo. This is yet to be publicly released, but should hit you in a few weeks if you own a Nexus One. Other phones most likely must wait a few months before Android Froyo is delivered to their phones.