Posts Tagged desktop

Linux Backups for Servers and Desktops

Posted by on Thursday, 18 June, 2009

Everyone wants to back up right? Well you will once you have totally lost the last years worth of work on a website and somebody breaks things severely!

Heres a quick and nasty backup HOWTO.

Database Dumps

mysqldump -u root -p mydatabase > mydatabase.sql

This dumps a database into a file, you can modify this to dump it offsite using ssh with this command.

su postgres -c "pg_dumpall" > pgdatabase.psql

If you use postgres you can change this to something like this

mysqldump -u root -p mydatabase > mydatabase.sql | ssh username@backup.comain.com “dd of=mydatabase.sql”

If you want to dump the entire database you can use

mysqldump -A -u root -p >entiredatabase.sql

This may take some time. To put this in a shell script and dump multiple copies and keep track of things you can use something similar to this

date=`date +%m-%h-%Y`

mysqldump -A -u root -p >${date}-fulldatabase.sql

This will expand to dump it into something like

06-Jun-2009-fulldatabase.sql

File Backup

FTP

To run a regular interactive FTP session:

lftp -u 'username,password' backup.yourdomain.com

To backup one or more files:

lftp -u 'username,password' backup.yourdomain.com -e "set ftp:ssl-protect-data true; mput /local/dir/files* /remotedir; exit"

You need to set ftp:ssl-protect-data else you will not be able to store the file. If you want to make this a default option, add it to the lftp.conf file. e.g. :

grep -qai "set ftp:ssl-protect-data true" /etc/lftp.conf || echo "set ftp:ssl-protect-data true" >> /etc/lftp.conf

To restore a file from the FTP server to your Machine:

lftp -u 'username,password' backup.yourdomain.com -e "set ftp:ssl-protect-data true;mget /remotedir/files* -O /localdir; exit" .

The -O option is not required it you wish to store to the current local directory.

To mirror a whole directory to the FTP server:

lftp -u 'username,password' backup.yourdomain.com -e "set ftp:ssl-protect-data true;mirror --reverse /local/dir/name remotedirname; exit" .

--reverse means that the ‘mirroring’ is going in the reverse direction than ‘normal’. i.e. from your server to the backup server. If you run man lftp there are a few other options to choose from. e.g. --delete to delete files on the backup server that do not exist locally. Or --continue to continue a mirror job. Or --exclude files to exclude certain files from the transfer.

To restore a whole directory from the FTP server to your machine:

lftp -u 'username,password' backup.yourdomain.com -e "set ftp:ssl-protect-data true;mirror remotedirname /local/dir/name;exit"

To create a nightly cronjob that uploads a directory to the backup FTP server, create a /etc/crond.daily/ftpbackup file like this:


#!/bin/bash
lftp -u 'username,password' backup.yourdomain.com -e "set ftp:ssl-protect-data true;mirror --reverse /local/dir/name remotedirname;exit" > /dev/null

Run

chmod +x /etc/cron.daily/ftpbackup .

Then check the files have been mirrored as you expect the next day.

Rsync

Rsync is a better option in some ways as it checks the MD5 of files and updates them if they are out of date, rather than re-copying the entire lot. Short but easy shell script to copy things over

#!/bin/bash
EXCLUDE=” –exclude *.tmp \
–exclude *.temp”
USER=username
HOST=backup.domain.com
BACKUPPATH=/backups

rsync –archive -vv –rsh=ssh $EXCLUDE $USER@$HOST:/etc/ $BACKUPPATH/$HOST/etc

Rdiff-backup

This is better again than rsync as it does versioning control and only backs up the difference in files.

To backup files

rdiff-backup /some/local-dir hostname.net::/whatever/remote-dir

To restore

rdiff-backup --restore-as-of now host.net::/remote-dir/file local-dir/file
rdiff-backup -r now host.net::/remote-dir/file local-dir/file

The -r command is the same as –restore-as-of

The main advantage of rdiff-backup is that it keeps version history. This command restores host.net::/remote-dir/file as it was 10 days ago into a new location /tmp/file .

rdiff-backup -r 10D host.net::/remote-dir/file /tmp/file

Other acceptable time strings include 5m4s (5 minutes and 4 seconds) and 2002-03-05 (March 5th, 2002). For more information, see the TIME FORMATS section of the manual page.

More examples can be found at http://www.nongnu.org/rdiff-backup/examples.html

This tutorial was compiled from several others, and props go out to http://rimuhosting.com and http://www.howtoforge.com


Working remotely

Posted by on Tuesday, 7 April, 2009

Introduction

PCAnywhere sells for dollars – gobs of dollars. Most of the equivalents also cost money. however, there are ways you can administer your Linux box (or even your Windows box) from another site. Depending on your requirements and restrictions, there are three or four methods you can use, and I’ll go through them. I deliberately don’t cover the issue of copying files here, as that is covered in other ways by using ftp, or www (or Point-To-Point software that usually isn’t allowed within a corporate environment). So, this tutorial only documents the ways you can get to your machine to run programs.


SSH

First off, I’ll cover SSH. SSH has pretty much outdated telnet as a means of communicating with your remote box. Telnet is universally accepted as being insecure as anything, even WHEN you turn on encryption – because the initial password and username go “over the wire” in cleartext. So, it’s ssh, and not telnet.

TTY only

It’s a terminal method of communicating with the computer at the remote end, instead of using a GUI. The old hands would remember their time with DOS, the even older hands will remember a time when there WERE no GUI programs, and it was ALL text.

Terminal is text. Pure and simple. If you don’t have an X session running on your local machine (by the use of either of X.org, XFree86, or Cygwin’s X server), then don’t count on being able to start up any X programs. It won’t work, unless you have X running on your local machine, which I’ll describe in another paragraph.

So – no graphics – unless you count those linedrawing characters and upper-ASCII characters, or using ANSI to provide colours. So don’t expect to start up a copy of notepad, xchat, or IE – it just won’t happen. It’ll turn up on the remote end’s desktop instead of your own, and that’s probably not what you want, as you have no way of terminating these programs. Unless you have …

SSH with X forwarding

If you DO have an X session running on your local machine, then count yourself lucky. Provided your system at home is set up to forward X connections, you can actually start an X program from home, and, several seconds (or perhaps even minutes) later, you’ll have a X program window appear on your screen. It’s pretty darn slow – rather like waiting for the RedSox to win a World Baseball Series. So no, you won’t be using it to play a game of UT2004.

Another point to mention. The faster the connection is between your box at home, and the box where you are, the faster the window redraws will happen. I find that it’s slow even over 10baseT. X forwarding will NOT work for connecting to your Windows box at home unless it too, happens to have an X server running THERE, for example, Cygwin’s X server, AND it happens to also have an SSH server running. Only Windows 2000/WinXP have the capability to do this, Windows ME and older do not. Now, down to the …

Nuts and bolts

So – you require a SSH server on your home box, configured to allow your login. You may also have firewalling issues to consider. Then you require some way of communicating WITH your server from where you are currently. For Linux, BSD, or OS X, there’s the command ssh.

  ssh  user@host

If your home machine happens to get assigned a dynamic IP when it connects to the Internet, you can often sign up to a redirection service, such as dyndns.org. This will typically redirect web requests, and may redirect other sorts of requests too, depending upon the service. So – point your local ssh client to the “handle” that you’ve signed up to with dyndns, or whatever, and that’s it, once you provide your password. If you’re bright like me, you’ll copy over your public key from your local machine over into your .ssh directory, and add it to .ssh/authorized_keys at the remote end. Pretty much once you do this, you never have to worry about passwords again. This presupposes you have set up sshd to allow the use of keys, rather than only passwords.

A note: your .ssh directory contents must ONLY be visible to the user themselves, and NOT viewable by others on the machine, or sshd will refuse to use your files. The dir MUST be chmodded to 0700.

  drwx------ viking  root  2 Aug  2 2003  /home/viking/.ssh

For Windows, there are a couple of alternatives. There’s PuTTY, which can do telnet, or ssh, and allows you to save session settings for a variety of hosts. The window that gets produced can be resized to any size you wish within the limits of your windowing environment.

Another option is a program called TeraTERM. I’ve never used this program, but apparently it has similar capabilities.

That covers tty access to your machine.


VNC

Then, there’s the Linux equivalent to RDP. It’s called VNC. It doesn’t have quite the same weaknesses as Remote Desktop Protocol, but I’d imagine there are one or two weaknessess too, dependent upon firewalling. You can run a vnc server that attaches to your current running X session (x0rfbserver), or you can start a completely different session (vncserver) with its own programs.

I already mentioned one of the disadvantages – firewalling. Another disadvantage is: these programs don’t behave like Windows programs unless your vncserver is also running on a Windows box. You gain none of the OLE advantages you would otherwise have with RDP sessions (if indeed, they support OLE yet, or COM, or whatever). They behave like static windows, often with a shared clipboard if your home window manager supports one (most do).

Now let me mention an advantage.

In comparison to RDP, VNC can be set up to either behave like RDP – one write, all read, or otherwise, all read, all write.It is really easy to change, although it might require that all viewers reconnect when you toggle the status and restart the server. This way, you can do what I believe Remote Desktops were MEANT to do. BOTH (or ALL) users can interact with the windowing session.


RDP

This is more for the WinHeads amongst you that need to administer a Windows XP box from a remote location. It’s a lot more difficult to actually keep this one safe, as you have to somehow allow your machine at home to acknowledge your initial RDP request from a remote location, and (thankfully in some cases) Microsoft have elected to make this default to NO. But, apparently, it can be done. This will only work with other RDP clients that understand the protocol that the windows box at home would use. In short, if work doesn’t support it, tough.

There is another disadvantage. RDP is typically many-read, one write by default, and I think it’s very difficult to change that. What this means is that – everyone in a RDP session can see what is happening, but only one person at a time can make changes. Once the person has made changes, the person MUST return control to the originator of the RDP invitation. If they don’t, you end up with a hung desktop.

Then, there’s always the Web.


Webmin

If you only have a limited range of tasks you ever need to do, then you may also want to consider using webmin. This acts just like a webserver, but sits on port 10,000 instead. Firewalling issues may rear their ugly heads again, like usual. But other than that, you can set up webmin on the remote end, and use your web browser to log in and select from a set of administration tasks you wish to perform. Don’t forget to set up webmin so that it will respond to requests from wherever you expect to work from, and NOWHERE ELSE. You can add firewalling to this too.

I also saw a “terminal” in the collection of applets that webmin supplies, so that if you just HAVE to have one, you’ve got one available. The only restrictions are: you’ll have to have java running in your local machine for the applet to work, and the shell is only opened to the same host that webmin sits on. But then, that’s what you wanted, wasn’t it?

So install webmin, and start it up at system startup. Then, when you need to administer your box, fire up your browser, and point it at http://your.box:10000/


Wrap Up

Well, there we go. Three ways of accessing your system at home from anywhere else in the world that happens to have an Internet connection. I have glossed over a lot of details such as how to set up ssh, webmin, and VNC, as there is normally enough documentation with the software to help out. After all, this is only meant to be a starting point. Good luck.

Revision 0.4 – 13-Nov-2004 16:59:00

Last-Modified: 2007-03-07 19:38:50