Saturday, December 08, 2007

7 Tips For Answering Your Tech Questions

We all come across problems in our computer ventures at some time or another. I have a number of tips that may help you find answers to your problems:

  1. Search: Searching google, or any other search engine, will often yield results, and it's always a good place to start.
  2. Search using your Error: If your problem is in relation to an error, and you have an error displayed on your screen try a search for that exact error. If someone has asked about it in a forum, or talked about it on there blog, then you will likely find your answer much more quickly.
  3. Documentation: Search the Handbook/Documentation relating to your operating system.
  4. Read the Manual: Read the manual pages relating to your problem.
  5. Mailing Lists: Search through the mailing list archives relating to your topic. You can also sign up for a number of list, and often you find solutions to problems that you haven't had yet ;-)
  6. Forums: Search the forums, relating to your distribution to see if someone else has answered your question.
  7. Ask: After exhausting all other options ask your question on a forum. Make sure that no one has asked your question before, and that you have searched every where else first. Also make sure that you place your question in an appropriate forum, in an appropriate place.
Have Fun!!!

Friday, December 07, 2007

7 Must Read OpenBSD man pages

In OpenBSD the manual pages are very important, well written documents. They comprise most of the written documentation for OpenBSD. Countless hours of work has gone into making them easy to read, and follow.

If you are new OpenBSD there a number of man pages which are a must read. These man pages can can explain much of the way that OpenBSD works, and many things that you can achieve using the system. Giving you a clearer perspective on your system.

  1. man(1): To view the manual pages you will need to use: man(1). The man(1) program displays a manual page in your terminal for you to read. For more information see: man(1).
  2. apropos(1): When your new to a system it can be difficult to know what manual page you need to read to achieve a task, enter: apropos(1). The apropos(1) program will locate and display all the commands containing a user specified keyword.
  3. hier(7): If your new to OpenBSD, or *nix systems make sure to check out the hier(7) manual page. This page details how the filesystem works, and gives you a good understanding of how the system is laid out.
  4. afterboot(8): When you first install an OpenBSD system you should check out the afterboot(8) man page. This well written man page, will tell you all the things that you should check/do after installing your system.
  5. packages(7): Once you have your system installed and configured you may want to add some software. If you would like to install binary packages check out the packages(7) man page.
  6. ports(7): If you would prefer to install software from source here is an overview of the ports(7) system.
  7. intro: If you would like to know what the numbers after the commands are, there is an explanation in the man(1) manual page, also you can read an introduction to each section here: intro(1), (2), (3), (4), (5), (6), (7), (8), (9).
Have fun Using OpenBSD :-)

Monday, December 03, 2007

Protecting Your Terminal

BSD Quick Tip
When ssh across my systems I often need to step away from the keyboard for a few minutes. This can pose a massive security threat to the system, therefore I think it's important to lock the terminal, this way I don't need to log in/out, nor leave the system insecure.

In all of the BSD's you can use a built-in utility called
lock(8). When you use:$ lockwithout any options you will be asked to enter a key twice. Then your terminal will be locked for 15 mins, after that time it will become available again.

Options:
To keep your terminal locked until you return, (no 15 minute timeout), use:$ lock -n
To use your normal user password instead of a key you enter use:$ lock -p
Personally I like to use these options all of the time, therefore I add an alias so I only have to type lock.

To Alias `lock -np` to `lock` in csh or tcsh:$ edit ~/.cshrcadd:alias lock lock -np
To Alias lock -np to lock in sh:$ edit ~/.shrcadd:alias lock='lock -np'

Sunday, December 02, 2007

Changing the Color Scheme in Gedit

Ubuntu Quick Tip
I find looking at a white background and black text a little daunting in Gedit, however in Ubuntu 7.10 (Gutsy Gibbon), you can easily change colour schemes and save your eyes. To change schemes:
In Gedit Go to Edit --> Preferences.
In the Preferences dialogue click on the Font & Colours Tab.
Then choose a scheme to suit you.

Humanise the output of OpenBSD's root mail

OpenBSD Quick Tip
I've discussed how to humanise the output of FreeBSD's root mail, and the same can be achieved in OpenBSD by running the following commands:# vi /etc/daily
change:df -klto:df -hikl

Humanise the output of FreeBSD's root mail

FreeBSD Quick Tip
The output of the root mail, daily run: disk status is in bytes, which is not quick and easy to read. To humanise this output and to show you the inodes being used do the following:
# vi /etc/periodic/daily/400.status-disks
change:df $daily_status_disks_df_flags && rc=1 || rc=3todf -hi $daily_status_disks_df_flags && rc=1 || rc=3

Thursday, November 29, 2007

Passwordless Login For SSH

I've recently set-up a new backup server, I wanted to be able to automate backups from my workstations to the server. I will be using OpenSSH (scp) as the transfer agent between the workstations and the server. By default the OpenSSH server asks for a password every time you login, therefore automation is impossible, without a bit of tweaking.

Creating an environment where passwords are unnecessary can be achieved using public-key cryptography. In this process we create unique identification between workstation (or other system) and server. The server can then recognise the user using a private/public key pair.

There are a number of steps that need to be completed, on both workstation and server, to achieve password-less logins. I have written the required server commands within the `ssh' command, to simplify the process. You will need to have a working OpenSSH server, and user login before beginning.

1. On the Workstation
On the workstation I login as the user who needs the ssh access to the server (this is really important as we are creating a key for this user.) If more than one user needs access, you will need to create keys for each user and system.

If no .ssh directory exists in users home you'll need to create one:
# mkdir ~/.ssh
# chmod 700 ~/.ssh
Now change directory into .ssh and create your ssh key (If you would like to use dsa encryption instead of rsa please use `ssh-keygen -t dsa' in the ssh-keygen command).
This text
, is used to represent your user input:
# cd ~/.ssh
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa): Press [Enter]
Enter passphrase (empty for no passphrase): Press [Enter]
Enter same passphrase again: Press [Enter]
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
f3:12:g5:23:1f:b2:f7:a0:65:b1:89:72:82:f2:23:g0 username@ssh.server.tld

*Note: If you decide to use a passphrase when creating your ssh key then you will be prompted to enter your passphrase every time you login, unless you use ssh-agent. For more information please see: ssh-agent(1), http://upc.lbl.gov/docs/user/sshagent.html

2. On the server
Now we need to go to the server and prepare the environment for ssh-keys. You will need to login to the server as the user who needs the ssh access. E.g. If I login as the user kris on my workstation I need to be user kris on the server, as well (If you have a different user names on the server and workstation please see note A at the bottom of the post.)
We are going to use one command string to complete all of the jobs on the server, before being prompted for a password:
# ssh username@ssh.server.tld \
'mkdir ~/.ssh; \
chmod 0700 ~/.ssh'
Password: * * * * * *

3. On the Workstation
Now we need to copy the .pub key from our workstation to the server.
# scp ~/.ssh/id_rsa.pub username@ssh.server.tld:.ssh/MY_keys
Password: * * * * * *
id_rsa.pub 100% 397 0.4KB/s 00:00
# ssh-add
Identity added: /home/kris/.ssh/id_rsa (/home/kris/.ssh/id_rsa)

4. On the server
Now we just need to verify the file copied over, and then put it's contents in the .ssh/authorized_keys file:
# ssh username@ssh.server.tld \
'cat ~/.ssh/MY_keys >> ~/.ssh/authorized_keys; \
chmod 600 ~/.ssh/authorized_keys; \
ls ~/.ssh/'
Password: * * * * * *
My_keys authorized_keys

5. On the Workstation
Now if you go back to your workstation you should be able to login to the server without typing your password:
# ssh username@ssh.server.tldor# ssh ssh.server.tld
Notes:
Note A. If you have differing user names on the server and workstation there is an easy solution:
After creating your ssh-key (# ssh-keygen -t rsa), edit the resulting id_rsa.pub (or id_dsa.pub) file and change the user name to the user name on the server.
E.g. If I have a user kris on my workstation and a user sirk on my server I would edit the id_rsa.pub file on the workstation from this:
ssh-rsa Asdasdasdc9asdaDp5Lq8+SMdZRPzgjr65i4684xbmtrZKMQ== kris@workstation.domain.tldto this:ssh-rsa Asdasdasdc9asdaDp5Lq8+SMdZRPzgjr65i4684xbmtrZKMQ== sirk@workstation.domain.tld
Note B. If you do not have a fully qualified domain name or an /etc/hosts file detailing your workstations, and servers IP addresses, you may also need to change the domain name used in your id_rsa.pub file to a IP address.
E.g. from this:
ssh-rsa Asdasdasdc9asdaDp5Lq8+SMdZRPzgjr65i4684xbmtrZKMQ== kris@workstation.domain.tldto this:ssh-rsa Asdasdasdc9asdaDp5Lq8+SMdZRPzgjr65i4684xbmtrZKMQ== kris@192.168.0.3
Note C. If you had another server running the OpenSSH server and you wanted to login from the same workstation using the new key, just copy your id_rsa.pub (or id_dsa.pub) to each server, like in the example above, making sure to copy the contents of MY_keys to ~/.ssh/authorized_keys.