Archive for category Tutorials

Using apt-get

Posted by on Tuesday, 7 April, 2009

Using apt-get / Installing aplications on Debian based distro’s.

This is just a quick guide to get you started on installing and upgrading software on you debian or debian based distro of linux. It is not meant to be a comprehensive guide. From here on in where I refer to Debian I mean any debian based or other distro of linux that uses apt-get.

Finding Applications / Packages.

Software for debian is stored in packages. These packages contains the files required for an application and also referances to other packages required to run the software. The fastest way to search the packages currently availible (assuming your package cache is up to date, more later) is to use apt-cache.

The basic syntax is: apt-cache search

ie. finding an irc client


$ apt-cache search "irc client"
cgiirc - web based irc client
ctrlproxy - An IRC proxy with multiserver support
...
...
...
tinyirc - a tiny IRC client
tirc - token's irc client
xchat - IRC client for X similar to AmIRC
xchat-text - IRC client for console similar to AmIRC
zenirc - Major mode for wasting time

I have shortened the output here …

The alternative in to browse a package archive such as packages.debain.org But keep in mind that depending on your installation sources and version some packages may not be available to you.

Installing an Application / Packages.

Lets, for example, choose to install xchat, an excellent IRC client. To do this we simply execute this at a command prompt as ROOT user. apt-get install xchat (To log in as root type ‘su’ at the prompt and enter you root password when prompted, if you are on knoppix or your user has sudo access preffix the command with ‘sudo’)

you should get something like the following:


Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
xchat-common xchat-text
Suggested packages:
libnet-google-perl
The following packages will be upgraded:
xchat xchat-common xchat-text
3 upgraded, 0 newly installed, 0 to remove and 350 not upgraded.

As you can see this will install extra required two packages. You maybe prompted to confirm the download of the packages. You should also receive a summury of sizes. On confirmation apt-get will download the packages and configure them. Some software will require user interaction and will prompt you for input.

To upgrade an existing package you similarly type apt-get upgrade

Upgrading and Updating apt-get

As the list of packages changes regularly you may need to update you cache of available packages. This is done by executing the following as root: apt-get update

To upgrade all packages on you system you can try the following (again as root) apt-get upgrade This will generally download alot of files !!!

Sometime packages will be held back because of conflicting dependancies, etc. To force this try apt-get dist-upgrade after running apt-get update then apt-get upgrade .

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


User communication

Posted by on Tuesday, 7 April, 2009

If you are running a multiuser system like Linux, you should expect to find other users on your system. (I guess that’s why it is a multi-user system.) Although there are many built-in mechanisms to keep users separated, sometimes you will want to communicate with other users.

Linux provides several tools to do this, depending on exactly what you want to accomplish. If you simply want to send a quick message to someone, for example, to remind him or her of a meeting, you might use the write program, which sends (writes) a message to his or her terminal.

In contrast to some other systems (say, the winpop mechanism under Windows), each line is sent when you press Enter. If you are on the receiving end of the message, the system lets you know who sent you the message.

If the person you are trying to contact is logged in more than once, you need to specify the terminal to which you want to send the message. So, if I wanted to talk to the user jimmo on terminal tty6, the command would look like this:

write jimmo tty6

If you omit the terminal, write is kind enough to let you select which terminal to which you want to send the message.

It might happen that someone tries the above command and receives the following message:

write: jimmo has messages disabled.

This message means that jimmo has used the mesg command to turn off such messages. The syntax for this command is

mesg n

to turn it off and

mesg y

to turn it on. Unless the system administrator has decided otherwise, the command is on by default. I have worked on some systems in which the administrator changed the default to off.

An extension of write is the wall command. Instead of simply writing the message to a single user, wall writes as if it were writing on a (where else) wall. That is, everyone can see the message when it is written on a wall, and so can every user. The wall command is often used by root to send messages about system status (e.g. when the system is about to be shutdown. Even if a user has disabled messages, the root user can still send them messages using wall.

If you want to have an interactive session, you could send write messages back and forth. On the other hand, you could use the talk program that was designed to do just that. When talk first connects to the other user, that other user sees on his or her screen

Message from TalkDaemon@source_machine… talk: connection requested by callers_name@his_machine talk: respond with: talk callers_name@his_machine

As the message indicates, to respond, you would enter

talk callers_name@his_machine

You might have noticed that you can use talk to communicate with users on other machines. If you omitted the machine name, talk would try to contact the user on the local machine (localhost). The preceding message would simply say

talk: connection requested by callers_name@localhost

You can also disable talk by using the mesg command.

It is common practice to use a couple of terms from radio communication when using talk. Because you cannot always tell when someone is finished writing, it is common to end the line with -o (or use a separate line) to indicate that your turn is “over.” When you are finished with the conversation and wish to end it, use oo (over and out).

Both of these mechanisms have some major problems if the user is not logged in: they don’t work! Instead, there’s mail or, more accurately, electronic mail (or e-mail).

On most UNIX systems (including Linux), e-mail is accessed through the mail command. Depending on your system, the mail program may be linked to something else. On my system, the default was to link to /usr/bin/mail.

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


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