Sunday, 26 March 2017

ALL/USER/-L/-R (1458/1150/256/52)
: Echolink ›› Current Logins Status Proxy List :: eQSO :: IRLP Status By Number :: WIRES-II :: PMR446 :: QSONET :: LPDNet :: D-Star :: AllStar Link

IRLP NodeOp Notes
Last updated August 25, 2005 20:06

This page is a collection of notes I'm gathering regarding the administration of an IRLP node as a relative newbie. They include notes on how to do things, as well as reminders of command line info, things I tend to forget if I don't use them often enough. My interest in this comes from my lack of knowledge of Linux in general, and lack of ability to remember anything longer than 5 minutes as I get older. When I need a command and don't remember the exact syntax (or haven't a clue), I look it up or ask others, and add to my notes. Sometimes, you'll see an IRLP mail list quote here if appropriate.

As I get older, one of the things I have more and more trouble with is learning something new. I discovered a long time ago that the best way to learn something is to try to teach it to others. You find out right away just how little you really know about it. Another thing I have more trouble with now is learning something today and remembering it six weeks from now when I need it again. That's why this info is here. Even if you don't use it, believe me, I will.

I hope you find something here that saves you time by not having to look it up in the piles of unorganized documentation on other web sites. If you find an error, please let me know to save others from chasing their tails with the wrong information. If there's something you'd like to see added, drop me an E-mail, tell me what it is, and I'll consider it. If you have a problem with it, chances are someone else will too, and they would appreciate it being on this list. These pages will grow, so check back when you have a problem. You just might find an answer to a long nagging question.

The original version of this page grew to a point where it was starting to load slowly, so I've broken several larger categories out to separate pages, and will continue to do so as it grows.

Please take the time to go through the Yahoo Group archives. There's loads of info there, and it's where I get most of mine. Before you post a question to the group, take the time to go back several months to a year, to make sure it hasn't been asked before. It gets irritating answering the same questions day after day because people don't bother to read the archives before asking. I'm sure that contributes to the seemingly "bad attitude" that the RTFM bunch displays now and then. Check first to see if someone else has asked the same question in the last several months. Also be sure to read the "Unofficial Manual" in the FILES section of the IRLP Yahoo Group. It's long, but it helps if you just stick with it. If you can't find an answer here, or in those other places, write me, or write the Yahoo list and ask. There are people who will know.

These notes are very informal and based on my installation of RH9 and IRLP v4.03 using IRLP board version 3.0. If you are running a different version, they may or may not work the same. As I move toward FC3 myself, I'll include notes.

This should be obvious, but I'll say it anyway. I accept NO responsibility if you break your node, or if things don't go as I say here! I take every precaution to be sure that the information is correct, usually testing it on my own node first. Dig around at your own risk. With tools such as WinSCP around, there's no excuse for you to not have a full copy of your node sitting on your Windows machine as backup. There's also a backup script for you to use.

I'll attempt to keep the list in some logical order, alphabetical when I can. Don't be afraid to use your browser's word search tool to look for key words or phrases.

Remember, man commandwill give you information on any Linux command. There will be much more available there, than what I'm giving you here. All you have to do is figure out all of those damned command line switches, etc.

After public notice of this site went out, I received a complaint about the font used. I used this font because I like it, and because it was the most readable of the fonts available to me. There's no ambiguity between characters in this font (except zero and letter O). Be aware, not everyone's web browser will display things the same. If you don't have Comic Sans MS, you won't display this page as it is designed.



G4EID Reflector Status Page
IRLP 3055

Commands and Notes

Audio Section (now combined)
Backup Your Node!
CD Command (change directory)
CHMOD (permissions)(chmod and chown are being reworked to combine)
CHOWN Long (improvement needed-will be rewritten)
Clock Setting
Computer Name Change
Connects While Channel Busy (controlling)
Custom Decode (I like shortcuts!)
Cron Section (now combined)
DHCP Change
DNS Address Location
Editing Files Warning!
Enable-Disable Node
File Permissions & Ownership (Default at install)
Hard Drive Space (how much?)
Help-malformed sysctl tree
IP of Remote Node
Local IP of Node
Locate Command (where's that file?)
Node Number Swap (2 nodes)
Password Changes
Pwd Command (where am I?)
Rc.irlp, Reloading
ReadInput (what's your node doing?)
Reboot IRLP Computer
Reboot, Should I?
Remote Login, disabling root login
Restore Your Node From Backup
Screen Blanker/Saver
Script Not Working?
Shut Down IRLP Computer
SSHD Port Change
SU and SU - (switch user)
Tail/Head Command (monitor logs realtime)
Terminal, Two At Once (part of Audio Settings)
Timeout Timer Changes and Disable
Wave Files, Upload Custom
WinSCP, Putty, What's The Fuss?

Everything below this line is linked from the above menu

Backup Your Node! (DO IT!)

There are a couple of easy ways to backup your node software. One is a built-in script called backup_for_reinstall. When you run it, it will create a backup directory on your node, compress everything you need to reinstall into a single file, and put it into the backup directory. Should there be a catastrophic loss, you somehow screw something up, or you upgrade the operating system (ie RH9 to FC3), you can restore from that file without losing your node number and settings.

As root:

You'll see names of files scrolling by as they are backed up. After it's done, look in /home/irlp/backup for a file called irlp_backup.tgz.

Windows users will likely prefer using a program like WinSCP to copy the /home directory and all of its contents to their Windows machine hard drive for safe keeping. That has the added advantage of being able to look at or compare files without having to uncompress them from the backup. It's comforting to know that you can undo a fubarian move by copying a file back into the appropriate directory.

I use both methods. Also see Restore Your Node From Backup.

BACK to last     Menu



Change into directory

The cd command is used to change directories, just as in MS-Dos.

For instance:
CD directoryname
will take you to any sub-directory of the one you are currently in (directory within the directory you are in).

To move to the parent directory of the one you are in (the level above where you are), you can use the same shortcut used in MS-DOS
Note the two periods after the space, after CD

If you need to move more than a level or two, it is easier to specify the full path and move directly into the desired directory with one command. If you were in the irlp directory and wanted to move to the S69 directory under custom, under audio, under irlp, you would do:
CD audio/custom/S69

You don't use the leading / for the first level down from where you are, so there's no / before audio. You would use the leading / if you were trying to go into a directory above your current level.

In order to get back to the irlp directory from the S69 directory above, you could CD .. three times, or you could specify the exact path. In order to do the direct path method, you also need to know the structure of the whole tree. In other words, you would not only need to know that you want to go to the irlp directory, but that the irlp directory is a child of the home directory in the root of the drive. So, the command:
CD /home/irlp
would be needed to get you back into the irlp directory.

You can also do it with
CD ../../..
since .. means to go back one level. That line literally means go back a level above the level above this level.

BACK to last     Menu



Change permissions

Understanding file rights and ownership is something that I've had the most trouble with since getting into this Linux thing. I will try to explain them in such a way that you can gradually understand them. It has taken me literally days of writing and rewriting this to get it clarified even to myself. I learned a long time ago that the best way to learn something is to try to teach it to others. You find out right away just how little you really know about it. There are some paragraphs here that you will need to read over and over again to digest. My apologies if this doesn't help you. It certainly helped me to write it.

The chmod command allows you to change access rights to files and directories. All files and directories have certain permissions assigned to them that give the users certain rights. I may use the words right and permission interchangeably in this text.

You can see permissions assigned to the files in a directory by using the ls -alt command. Doing so in a directory such as custom, you might see something like:

Non-graphic example below

There's lots of information presented there. All you have to do is figure out what it means! Let's see if I can shed some light on some of it.

Non-graphically, for the visually handicapped, sample lines for the rc.irlp and environment files look like this:
-rwxr-x---    1 root     root            3240  Feb 17  17:34 rc.irlp
-rwxr-x---    1 root     repeater     4792  Apr 14  00:05 environment

Skipping to the easy stuff first, on the right, you see the filenames. The blue single and double dot entries in the image are for parent directories. Moving to the left, the time and date that the file or directory was created or last modified, and the size are given. At this time, I don't know why the time is replaced by the year in some cases. If someone knows, let me know and I'll put it here. Left of middle shows ownership on the left, and group on the right. For instance, rc.irlp is owned by user root and belongs to the group root. The file environment is owned by root and is in the repeater group.

A group is a way of assigning multiple users the same rights/permissions to files and directories in that group. Only root can assign users to groups.

What about all those -rwxr-x--- gobbledygook letters over on the left?

     d means the item is a directory, rather than a file
     r means the file or directory is readable (viewable)
     w means the file or directory is writable (edit or modify the file)
     x means the file or directory is executable (can be run if it is an executable)
     - means the file or directory has no permissions assigned

The columns that the letters appear in are assigned. The first one is set aside for indicating a directory. After that, they are in groups of three. The first group of three letters indicates permissions for you the user. The second group of three letters indicates permissions for your group. And, the third group of three letters indicates the permissions of other users.

The line for rc.mixer shows -rwxr-x---, indicating it is a file (no d in first column). Further, I have read, write, and execute permissions, the group has read and execute permission, and other users have no permissions at all.

I'm "familiar" with a couple of ways to change permissions at the console.

With one method, you use a series of letters and symbols in specific order to assign rights to a file. You start with the "who" position, given as one of u for user, g for group, o for other, or a for all. Next, you specify whether you are changing the whole value with =, or adding a value with +, or removing a value with -. The next letter specifies the right you are assigning with the action. It would be given as r for read, w for write, or x for execute.

Examples using the file foo.
If you wanted to give everyone read, write, and execute rights, you could use:
chmod ugo=rwx foo

Because a (all) means the same as ugo, it could also be shortened to:
chmod a=rwx foo
meaning all may read, write, and execute the file.

To turn around and revoke write permission from group and other on the same file, you could use:
chmod go-w foo

To demonstrate adding a right, I could add back the write permission to group with:
chmod g+w foo

You can also chain commands with a comma between:
chmod g+w,u-w foo
would give write permission to the group and take write permission from user.

There are all sorts of angles you can come at this from. Here's a much easier one to understand, and one that WinSCP can use directly.

A simple line like:
chmod 751 rc.irlp
can be used to assign rwx to user, rx to group, and x to other.

But where did you I get the 751 from?

It came from this chart:
     7 full
     6 read and write
     5 read and execute
     4 read only
     3 write and execute
     2 write only
     1 execute only
     0 none

If you want to assign your user permissions to full, group's permissions to read and execute, and other users to execute only, the number from the chart is 751. Use 7 for you the user, the 5 for the group, and the 1 for other users. Use the chmod command to assign them to the file.

chmod 751 rc.irlp
assigns permissions as -rwxr-x--x

To make the same change from within WinSCP, simply right click the rc.irlp file, click properties, and change the permissions box to read 0751. Click OK and then refresh the window.

For those who know about the concept, you can relate the above to bit mapping. In the chmod 751 rc.irlp command above, I assigned read and execute permission to the group with the number 5. The number 5 actually represents a bit total for that position, and is determined by adding the three bit values of read plus write plus execute. The left bit is assigned to read permission, and has a value of 4 or 0 (on or off). The middle bit is assigned to write permission, and has a value of 2 or 0 (on or off). The last bit is assigned to execute permission, and has a value of 1 or 0 (on or off). So, to assign read, no write, and execute permission, you would add the bits, 4 for read, plus 0 for write (permission turned off), plus 1 for execute, equals 5. This correlates to 5 on the chart above for read and execute.

BACK to last     Menu



Chown Long
(this will be rewritten and shortened as time permits-for now it's here in case you need it)

This needs to be changed. It was received from someone else and hasn't been cleaned up. I'll leave it for now, but will got through it sometime in the future. It contains info on multiple commands.

CHOWN(1) User Commands

chown - change file owner and group

chown [OPTION]... OWNER[:[GROUP]] FILE...
chown [OPTION]... :GROUP FILE...
chown [OPTION]... --reference=RFILE FILE...

This manual page documents the GNU version of chown. chown changes the user and/or group ownership of each given file, according to its first non-option argument, which is interpreted as follows. If only a user name (or numeric user ID) is given, that user is made the owner of each given file, and the files' group is not changed. If the user name is followed by a colon or dot and a group name (or numeric group ID), with no spaces between them, the group ownership of the files is changed as well. If a colon or dot but no group name follows the user name, that user is made the owner of the files and the group of the files is changed to that user's login group. If the colon or dot and group are given, but the user name is omitted, only the group of the files is changed; in this case, chown performs the same function as chgrp.

============ ============= ============= =============

Jude <jdashiel@shellworld.net>

Subject: An overview of users, groups and file permissions

Hi everyone:

As I said in a message yesterday, I am about 4 or so days behind in my mail reading, so I strongly apologise if this has all been clarified already. I have just been reading the thread dealing with file permissions and there seems to be a bit of confusion about how it all works, so I thought I'd write a short note of explanation to clarify it all and put it all in one place.

To start with, every user on a linux system has an account and an associated user-ID number. There are also special user accounts set aside for system processes, most notably that of mail. The details for all user accounts, including these so-called pseudo-users, can be seen in the file /etc/passwd. This typically lists the account names along with their user-ID numbers, and also contains the kind of information you typically see with finger, such as home directory, login shell, phone number (if filled in), etc. The password is encrypted, and if you have shadow-passwords enabled, the encoded password will be stored in /etc/shadow. To alter passwords, use the passwd command. You can change any account's password as su/root without knowing the old one (just type "passwd accountname"). The login shell can be changed with chsh. The finger information (like name, phone, etc), can be changed with chfn.

OK, that's sorted that out. Users can also be in one or more groups. Group information is stored in /etc/group and is in fact some-what meant to be manually edited. So after you make a group with addgroup, you can edit /etc/group and put names in it. I'll show you an example from my /etc/group file


Note that the syntax is pretty important and I've had stuff not work when something added a rogue space in there (it wasn't me, your honour). This example means that Amanda and I have group access to the audio group, which provides us with read/write access to the audio devices. This also provides me as sysadmin the ability to prevent access to some programs based on this, if I so chose. Another example is the dip group. Debian installs all the PPP stuff with the group owner of dip (presumably dial-up IP). This means that anyone in the dip group can put the PPP connection up without anyone else aside from SU being able to do it. I'm sure you can appreciate the advantages of this approach. This also illustrates the point that there may already be groups set up to do a particular job you need done, so check these out before bothering to create your own.

OK, now to files. To see the permissions on a file, use "Ls -l". At the left end of a file listing, you will see a 10-character string listing how the permissions are set. It might look something like this:


The first character designates the type of file, and d is for directory. The next 3 are user permissions, the next 3 are group
permissions and the last 3 are the permissions for everyone else. So, this example gives a directory which is readable and executable by everyone and writable by the owner. An executable directory is one that can be entered, kinda important for say, an FTP site.

Following the FTP example, you might want to set an incoming directory. Say you have a group called ftp-admin which is a group of
users who administer your FTP area. The directory is owned by root. You want the admins to be able to examine and move incoming files so you don't have to do it all, and you want people with anonymous FTP access to merely be able to upload files and nothing else. You'd set up your permissions as follows:

drwxrwx-wx 1root ftp-admin 1024 Jun 14 20:28 incoming

So how do you do this? Well, there are 2 ways to set permissions with chmod. One uses octel representations of the permissions, with 4 for read, 2 for write and 1 for execute. So the above would be 775. This can be a little confusing though if you didn't have enough coffee this morning, particularly if you just want to change existing permissions, so there is also a way to add or subtract individual permissions. You do this by using a letter designating user, group or other (U, G or O), a plus or minus depending on whether your adding or subtracting, and then the permission (R, W or X). So to make that incoming dir word-readable, you could type:

chmod o+r incoming

Or if you wanted to remove the group read permission from the same directory you could type:

chmod g-r incoming

Of course, there will be times when it is quicker to use the numbers, so it's really up to you as to which you want to use.

OK, so how do we set owners and groups? With the chown command. This command is pretty self-explanatory so I'll let you read the manpage, but for a simple example:

chown root.ftp-admin incoming

Changes owner of incoming to root and group to ftp-admin.

chown geoff state-secrets.txt

Changes owner to geoff and leaves group intact. A good time to use this command is if you download a batch of files in a tar archive and the owner/group permissions are screwy. You can use wildcards with chown which is also cool. sometimes I copy files into Amanda's home directory and forget to change the ownership so she can actually read them, and a quick wildcard chown is just what's needed to fix it and save further embarrasment.

So what determins the default permissions? Your umask. this is probably set by a script, but you can of course change it with the umask
command. What it is is a set of permissions that, when subtracted from 777, determines your file permissions. So my user account mask of 002 will lead to a default permission on files I create of 775 or rwxrwxr-x. To check your umask, type "umask". Of course, you can always chmod the files afterwards.

One thing left. What's this set UID root thing? Note that this can be dangerous so be careful with it. There is an extra bit in the execute permissions that do certain things. The extra bit in the user tells the file to assume that it is the user owner that is actually using it. So if a program is set UID root, the program will act as if root is running it, regardless of who is actually running it. Obviously, you'll never want to set, say, rm as set UID root. Nice and dangerous.

So how can you see what's set uid root and how do you set it? Well, if a program is set uid, the x in the user set will be replaced with an s. You can therefore do a "chmod u+s programname" to set it. It's also possible to do it numerically, but I'm not sure how to do it (never have). To find out how and to see what the so-called "sticky bit" for the other fields do, check the chmod manpage.

Hope all this helps someone.



Don't know about the symbolic stuff, but here is how I keep it straight.

When you do a, say, Ls -la you get something like this:

drw-r--rwx foo

Break it out into 4 parts. First character: directory, link, whatever.
Next 3 characters: user
Next 3 characters: group
Next 3 characters: world

Each 3 characters are represented by a number. From left to right it's
4 2 1.

So in the above example the directory foo has 647 permissions.

rw- equals 4+2+0
r-- equals 4+0+0
rwx equals 4+2+1

BACK to last     Menu



Clock Setting on the Node Computer

To check the computer date and time:

To set the date and time:
date mmddhhmmyyyy

where mmddhhmmyyyy is the 2 digit month+2 digit day+2 digit hour+2 digit minute+4 digit year

Example - it's 0048 (local) on April 3, 2005. The command to set the clock to that time is:
date 040300482005

After setting the time, check it again with the date command to be sure you did it right. If it is correct, you can write it to the cmos hardware clock with the command:
hwclock --systohc

I highly recommend installing ntp to keep your clock up to date. It came installed on the RH7.x and FC3 versions, but not with RH9. Once installed, it is trouble-free. I needed a ton of help with the installation and don't remember enough of that process to write it up at this time, but hope to in the future.

After ntp is installed and running, you can add the cmos clock setting command to the crons to run once a day if you like.

From Dave, K9DC, here is a good explanation of the reference files for time:

The daylight/standard behavior, amount of offset and date of the change is controlled by the file referenced in ZONE. For example, if ZONE="America/Chicago" the node changes its zone from CST to CDT on the appropriate date. If ZONE="America/Indianapolis" the nodes stays on EST year round (we do not observe daylight time in most of Indiana). All of the various timezone files are buried in /usr/share/zoneinfo/ and subdirectories, such as /usr/share/zoneinfo/America/Indianapolis.

Basically, find a city in zoneinfo structure that behaves exactly like your timezone and stick that in the ZONE field. Reboot the machine, set the clock (or let ntp do it) and all will handled from that time on.

If you have the timeconfig utility on board (FC3), just run that. If you are using the IRLP version of RH9, you will have to mess with /etc/sysconfig/clock manually, since timeconfig was left off of the RH9 IRLP CD.

The significance of this is that all cron jobs consider the time of day of the local timezone, even if the hardware clock is set to GMT. So if you want your nightly updates to occur 03:00 local time (or anything else you want to run based on local time), then your node needs to be set in the correct local timezone. Setting your node to "GMT -6" means your node may be off local time by an hour for half the year (Central time right now is GMT-5, in the winter it is GMT -6).

Oh, by the way... any USER on the system CAN be set to a different timezone with user environment variables. :)

-Dave K9DC

BACK to last     Menu



Computer Name Change

As root, edit your hostname in /etc/sysconfig/network (won't take effect until reboot or reloading network config).

Short story: I used this recently to change the computer name on a visually handicapped friend's node so it would be easier* for me to be sure which computer I was remotely logged into. In this particular case, it created a problem that scared us a bit. I changed the name and then rebooted the computer. When it came back up, I couldn't log into it from the Internet, and he couldn't log into it from his LAN. He didn't even have a monitor on his node computer, so the option of logging in from the console would be difficult (I've talked someone through it though). After unsuccessfully trying several times to log in, I tried connecting to the node from mine to see if it might actually be up and running. It was! Whew, it wasn't completely broken. Keeping the story short, I talked with someone about how I might to reestablish remote access. He suggested that we try to Telnet into the node. Telnet is not normally enabled on a stock installation, but it happened to be on this one. Since we were able to get into it, the next suggestion was to restart the sshd service. Obviously, access to the console would have been less stressful. To restart sshd,

As root:
service sshd restart

That fixed it. WinSCP and Putty worked locally and remotely. Why this happened, we don't know. If it happens to you, login and restart sshd service as above. It won't hurt a thing, and in our case, it fixed it. We rebooted a couple of times, even shutting it completely off for awhile, to be sure it was going to be good at startup. All was good again. It is possible that a second reboot in the beginning might have fixed it. But, the node was up and running, I was still gathering ideas to try, and I didn't want to take a chance on breaking it completely.

*The computer name is displayed as a part of the prompt while you are logged in.

BACK to last     Menu



Connects While Channel Busy
Controlling connects while the channel is busy (default is to disallow)

On most nodes, if you try to connect to them while there is activity on the channel (COS active), you will "The node you called is being used locally." That's because the default setting is to not interrupt a QSO already in progress. Any valid signal on the IRLP node receiver, whether it is a repeater node, or a simplex node, will prevent someone from connecting. If you to WANT people to be able to connect while the frequency is in use, you can change it. In the environment file, there is a line that reads export REPORTBUSY=YES. In mine, it is on line 28. If you change that line to read export REPORTBUSY=NO, calling nodes will be allowed to connect, even though there is activity on channel.

Note: Neither end will actually receive a connect message until the COs active state changes to inactive (node input is quiet).

BACK to last     Menu



Custom Decode
Why dial all those digits for nodes and reflectors you connect to frequently?

Custom_decode is probably the first file you need to get familiar with after you get your node on the air. You can do so much neat stuff with it. You could even turn the coffee pot on with it if you wanted (true)! Below, are some samples out of my custom_decode file, with some commands changed to protect the snoopy.

First, you need an ON-OFF command. One theme you'll see throughout my commands is using 0 for OFF and 1 for ON. It's easier to remember. So, if I say 71 is going to be my OFF-ON control, I use 710 for OFF, and 711 for ON. See below. Notice I've put two commands on the line for OFF. While not necessary, I wanted to be sure the node wasn't connected before disabling it. 710 disconnects the node if it is connected, and then shuts the node down. If it isn't connected, the disconnect doesn't hurt a thing.

Next, I wanted to have shortcuts for connecting to my favorite nodes and reflectors. In this case, I used star as a prefix for nodes, and pound for reflectors. Additionally, I wanted to disconnect from anything I was already connected to before connecting to the desired destination. Remember, star is designated with capital S and pound with capital P. If you would rather be warned that you are already connected, leave out the portion below.
"$SCRIPT"/end ;

Notice that node 3148's shortcut has notimeout after it. That disables the activity timeout timer on both nodes. Normally, the node with the shortest timer controls the link, but with notimeout added, the nodes will stay connected until one or the other manually disconnects.

After the node and reflector shortcuts, you can see some commands that I'm experimenting with. They are rem'd (remarked) out so that they are disabled. This is how you can put test commands in and disable them when you aren't working on them.

Below that, are two version of *69 (star sixty-nine). The first is an actual *69 function and the second just gives a report of the last call waiting, incoming, and outgoing calls.

The 0 (zero) command gives the node status (connected to xxxx or link clear), and the 1 command announces the time.

Look through these commands and see an additional note at the end. You should see from what is below how to do most of the common commands.


# This is the custom decode file. Make sure all valid codes exit with "exit 1".

if [ "$1" = "710" ] ; then "$SCRIPT"/end ; "$SCRIPT"/disable ; exit 1 ; fi
if [ "$1" = "711" ] ; then "$SCRIPT"/enable ; exit 1 ; fi

# Frequently called nodes and reflectors
if [ "$1" = "SA" ] ; then "$SCRIPT"/end ; call stn3936 ; exit 1 ; fi
if [ "$1" = "SB" ] ; then "$SCRIPT"/end ; call stn3148 notimeout ; exit 1 ; fi
if [ "$1" = "PA" ] ; then "$SCRIPT"/end ; connect_to_reflector ref9200 ; exit 1 ; fi
if [ "$1" = "PB" ] ; then "$SCRIPT"/end ; connect_to_reflector ref9453 ; exit 1 ; fi

# For Idle_Connect - connects to specified node/reflector if there's no other activity
#if [ "$1" = "C1" ] ; then ("$CUSTOM"/idle_connect &) ; exit 1 ; fi
#if [ "$1" = "C0" ] ; then ("$CUSTOM"/idle_connect die &) ; exit 1 ; fi

# Star 69 functions
if [ "$1" = "S69" ] ; then "$CUSTOM"/callback ; exit 1 ; fi
if [ "$1" = "P69" ] ; then "$CUSTOM"/star69 0; exit 1 ; fi # report

# Status Query
if [ "$1" = "0" ] ; then "$CUSTOM"/chk_irlp ; exit 1 ; fi

# Speak the time
if [ "$1" = "1" ] ; then "$CUSTOM"/speaktime ; exit 1 ; fi

exit 0

A variation on the above lines is to use decode xxxx for the command. For instance, the line
if [ "$1" = "SA" ] ; then call stn3936 ; exit 1 ; fi

to connect to 3936, could also read:
if [ "$1" = "SA" ] ; then decode 3936 ; exit 1 ; fi

But, using decode means you also have to include any prefix you have defined in the environment file. So, if you had made this change in your environment file:

export DTMFPREFIX=123

the line:
if [ "$1" = "SA" ] ; then decode 3936 ; exit 1 ; fi

would have to read:
if [ "$1" = "SA" ] ; then decode 1233936 ; exit 1 ; fi

for it to work.

Also, the notimeout function won't work on decode.

BACK to last     Menu



DHCP Change

> I have 2 nodes. I need to swap my conections.
> I have one node DHCP and need to change it to a static IP and another
> node that has a static IP I need to change to DHCP. How do I do this?

The most *reliable* way is to edit one or two files:


The first file contains most of the information, except that the default gateway may only appear in the second file above. If GATEWAY is in both files, make sure it is the same (or remove it from one).

[Note: Don't do this remotely. The first step will kill your access! (experience)-AGØN]
If you are on the console, you will then need to enter the following commands:
ifdown eth0
ifup eth0

A reboot will also do the trick. -Dave K9DC

Note: that's eth-zero, not letter O

Also be sure to check/change your port forwarding on the router if you change IP addresses.

BACK to last     Menu



DNS Address Location

The IP addresses for your DNS servers should be found in the /etc/resolv.conf file. It may be set to your ISP's DNS, or to your router's address.

BACK to last     Menu



Editing Files Warning

You MUST be careful when editing scripts or other files in the system to be sure that you don't inadvertently add a return or linefeed to a long line. If you use an editor that wraps a line, the file will probably not work.

Everyone develops their own preference for editors, but the one that's included in the IRLP installation (Pico) works fine for simple changes if you load it with wrap turned off. If, like me, you prefer to do all of your editing from your Windows machine, Notepad will work with word-wrap turned off. I prefer an old version of Ultra-Edit as an all around whatever kind of file editor in Windows.

Using Pico, load it like this:
pico -w filename

In Notepad, check Format and be sure that there's no check-mark beside Word Wrap.

BACK to last     Menu



Enable-Disable Node

Quick note. When I installed my node software, the instructions didn't say anything about having to manually enable the node the first time. I think it assumed the computer would be rebooted. Being a total newbie, I had no clue why the node wouldn't work after install. If this happens to you, reboot the computer and it should come up fully operational. This should be a one time situation.

There are several ways to disable and enable a node. One of them is provided in the stock custom_decode file in the custom directory. You can control it via touch-tone from your radio. It is rem'd out in the file, so all you have to do is edit the file and remove the hash (#) marks at the beginning of the two lines below.

# if [ "$1" = "12001" ] ; then "$SCRIPT"/disable ; exit 1 ; fi
# if [ "$1" = "12002" ] ; then "$SCRIPT"/enable ; exit 1 ; fi

When done, it should look like:
if [ "$1" = "12001" ] ; then "$SCRIPT"/disable ; exit 1 ; fi
if [ "$1" = "12002" ] ; then "$SCRIPT"/enable ; exit 1 ; fi

The above lines allow you to dial 12001 to disable the node and 12002 to re-enable it from your radio on the input to the node. You may edit the custom_decode to change those codes to whatever you want, as long as they don't conflict with other functions.

If you want to disable the node via the console,
as repeater:


Note that the enable command can't be typed directly as a single word like the disable command. That's because there is another enable command that is unrelated and in the path. Type it as above and it will work.

The node may also be disabled and re-enabled in the cron file per a schedule. Some owners disable their node overnight, turning it back on again in the early morning. To do this, you'll need to get familiar with the workings of the cron file. I've added a section on crons, however, I'll give you an example here that you can examine and modify.

The proper way to add your own crons is by adding a file in the custom directory (it isn't there by default) called custom.crons.

Create the file.

As repeater:
cd custom
pico -w custom.crons

In that file, you might type two lines that look like:
0 0 * * * (/home/irlp/scripts/disable &>dev/null 2>&1)
0 6 * * * (/home/irlp/scripts/enable &>dev/null 2>&1)

45 23 * * * (/home/irlp/scripts/disable &>dev/null 2>&1)
30 6 * * * (/home/irlp/scripts/enable &>dev/null 2>&1)

In the first example, the node will be disabled at midnight and re-enabled at 0600 daily. In the second example, the node is disabled at 2345 and re-enabled at 0630. That should be enough to let you come up with your own scheme.

In pico, write the file to disk with Control-O, confirming the filename with a return, and then Control-X to exit back to the command prompt. Make sure permissions are correct with:
chmod 750 custom.crons

Trust me on that one. I'll do a section on chmod later, when there's more time and I'm more confident in my ability to do it justice.

After creating or changing the custom.crons file, you'll need to reload the crons to import that new data into the main crons list.

As repeater (node must not be connected to another at the time):
update files

Check to see that the new lines are included in the crons with:
crontab -l

Here's a trick, compliments of Jim Price, WW4M. To enable the node silently (without the verbal announcement), add the following line instead of the one in the examples above. Change the time per your own needs.

0 6 * * * /bin/touch /home/irlp/local/enable >/dev/null 2>&1

Also see Cron Tips and Custom.crons.

BACK to last     Menu



File Permissions & Ownership
What were they originally?

Be careful here. Read AND UNDERSTAND the warning that I give right before the script lines at the bottom of this section. If you don't, you might kill your node!

Ever wonder what the default permissions and ownership were set to so you can put them back when in doubt? While looking through the reinstallation script, I found a section that sets ownership and permissions for all of the files and folders after reinstalling them. In order to be sure you have the latest information, you should pull the latest reinstall script from the servers at the time you need them. Go to the New-Installs page and look for the re-install from backup instructions. Scroll down in that document until you find the area that reads something like Downloading the Reinstall Script from the Server. Follow the instructions for downloading the reinstall script.

After you have it, use WinSCP to copy it to your PC and open it in a text editor or viewer. Scroll down near the bottom of the file and look for #### Setting File Permissions ####. Below that line is the script that sets file and folder permissions. I'll include what is in the current (June 9, 2005) version of the script, but PLEASE do as above and get the LATEST information from the web site in case Dave makes changes.

WARNING! You need to be careful looking at this list to notice that some things are changed more than once. For simplicity, a complete folder might be set with permissions or ownership and later a specific file or files within a folder changed (see rc.irlp and others). Be sure you understand what is being done. If you give the wrong ownership or permission to a file, your node may cease to work properly.

In the lines below, "$ID" is /home/irlp

chmod 660 "$ID"/audio/*
chmod 750 "$ID"/bin/*
chmod 750 "$ID"/scripts/*
chmod 750 "$ID"/custom/*

chmod 750 "$ID"
chown -R repeater.repeater "$ID"/*
chown repeater.repeater "$ID"
chmod 750 "$ID"/custom/rc.irlp
chown root.root "$ID"/custom/rc.irlp
chmod 750 "$ID"/custom/environment
chown root.repeater "$ID"/custom/environment
chown repeater.repeater "$ID"/.pgp
chown -R repeater.repeater "$ID"/.pgp/*

Again, get the most up to date information from the latest reinstall script. Don't rely on what is above.

BACK to last     Menu



Hard Drive Space
How much have I used, how much is left?

df -h

BACK to last     Menu



Help-malformed sysctl tree on free

What is this? Ignore it. It is known to the software author and does no harm, other than bug us by being on the screen. Get on with life!

From VE7LTD:

The problem here exists with the /dev/parport driver in the Linux kernel. The DTMF process tries to close any open "files" associated with the parallel port when it starts.

The error is harmless, and is well known to happen on ALL IRLP nodes, no matter what Linux OS it is running, as long as it is running the Linux kernel.

Since the only reason that DTMF is reset every call is to adjust the timeout values, the way this error will be fixed it to change the way that the DTMF process reads and writes files, and operates.

I have been working on this, but since this error is not fatal or harmful in any way, it has not been fixed.

Dave Cameron

BACK to last     Menu



IP of remote node

Now and then, you might need the IP address of a node that changes IP frequently. I administer a node that changes IP address frequently. Quite often, I can't get the IP from the /custom/hosts file because it is has changed since the file was updated. Normally, you can get the IP address by simply logging onto your node's computer as repeater and dialing up the node you need the IP for.
As repeater:
decode 1234

As it makes the connection, the IP address of node 1234 will be displayed to you on the screen. The problem with this is that you connect to him when you don't necessarily want or need to. Why bother the owners or users when there's no need? There is a script that will do the same thing without connecting. It is in the files area on the IRLP Yahoo Group and is called irlphost. Download the script and put it in the /home/irlp/scripts directory. Note, this is a tar file. If you have WinZip, it will extract the script for you.

See syntax example below.

As repeater:
irlphost 1234

Because the files in the /scripts directory could be overwritten by updates, you really should put your non-stock scripts in the /custom directory. Syntax for that path is below.

As repeater:
custom/irlphost 1234

BACK to last     Menu



Local IP of Node Computer
Where is the (fixed) IP address of the node stored?


If you change this address (fixed IP-not DHCP), you must reload the network configuration.

As root:
ifdown eth0
ifup eth0

BACK to last     Menu



Locate Command
Where the heck is that file?

Locate is a really useful command for finding a file. If you don't know what directory the whizbang.xyz file is in, simply type:

locate whizbang.xyz

A very helpful tip was just sent to me by Dave, VE7MQ. Thanks, Dave. This is the kind of info I need on things that I barely understand, and this probably explains why locate has sometimes not worked for me.

The 'locate' command uses a built-in database of all files on the system. However, this database is only updated once per day, by default. Thus, a new file will not be found by 'locate' until after the daily update has occurred. To do a manual update, as root, type: 'updatedb'. [The update is triggered by one of the root crons.]

BACK to last     Menu



Locking out a node

Locking out a node is not to be taken lightly. To quote from the Unofficial Manual: "This method should be used as a last resort, as it is not in the spirit of IRLP to lock out a node without reason. Nodes found locking out all nodes but a precious few will be asked to remove themselves from the IRLP general system and be added to a private system." However, if you feel you must, it is easily accomplished. Be aware that a lockout blocks connections both to and from the node you lock out.

To lock out a node or prevent connection to a reflector, create a file called lockout_list in the custom directory. As before, you can create the file with your favorite text editor. In the file, will be a list of nodes and/or reflectors to be locked out of your node. Nodes are listed by stnxxxx, where xxxx is the node number. Reflectors are listed as refxxxx, with xxxx being the reflector number. The following example will use pico to create a lockout for nodes 1234 and 4321, and reflector 9000. There's a carriage return after each node/reflector number.

As repeater:
pico -w /home/irlp/custom/lockout_list

The -w isn't a necessity in this case (no long lines), but it's good to stay in the habit of using it for those times when it is. Save the file with Control-O, confirm the filename, and exit pico with Control-X.

If your node happens to be one that isn't allowed on reflectors because you haven't taken steps to remove carrier tails, IDs, courtesy tones, or pulseback, you might want to lock yourself out of all reflectors. This can be done by using the keyword ALLREF instead of trying to list them all.

BACK to last     Menu



Node Number Swap
(between two nodes)

> One of several nodes I built needs to change node numbers with another
> node. I know I must copy the pgp.keyrings over, but what else?

You need to swap two files from each node. Both are located in

The first is secring.pgp which is the actual secret portion of the key pair (and technically the only one that needs to be swapped) Plus the ascii version of public key stnXXXX.asc where XXXX is your node number. This needs to be moved simply because it is unique to your node and provides an easy way to look up the KeyID should it be necessary. There may be backup (.bak) versions of each file. You can just delete those.

In addition, you will need to swap change stn numbers in the environment file (you can edit this change in). If one of the node numbers ends in zero, be sure to note whether that node number is 3 or 4 digits long (stn473 or stn4730 as an example). It must be replaced in the environment file in the exactly the same format. The reason for this oddity is legacy node numbers were 3-digits long, but as the installs team has been doing re-installations, we have been changing 3-digit node numbers to 4-digits when creating new keys, so there are some of each.

-Dave K9DC

BACK to last     Menu



Password Change for User

You'll probably get tired of reading this over and over, but do set a secure password for your IRLP Linux box. You should have at least two logins and passwords, one each for root and repeater. See below.

Password changes: log in as the user whose password you want to change and type

You can change any user's password on the system while logged in as root.

Example as root:
passwd repeater
Then answer the questions to supply a new password for user repeater.

You should check your node to see if you have a password specified for user repeater. The RH9, IRLP 4.03 version of the installation did not do this by default. You could only login as root and then su - repeater. If you can't login as repeater, you should correct that.

Root and repeater should have different passwords, and it is recommended that the root password be more secure, harder to guess/crack. User repeater only has limited access to the system and you can setup an easier to remember password for it. Setup a repeater password as above. Then, don't login as root unless you have to have access to specific root items.

What's makes a password secure? Is it easy to remember, made up of words or a phrase? Then it isn't very secure. For security, a password should have both alpha and numeric, as well as both upper and lower case letters in it. And, the longer it is, the harder it will be to crack if someone wants to try.

BACK to last     Menu




As repeater:


BACK to last     Menu



Or, where the heck am I?


You'll see your current directory path. Also see CD.

BACK to last     Menu



rc.irlp reloading

Reloads IRLP software without rebooting the operating system.

As root:

BACK to last     Menu




Monitors what your node internals are doing. See what touch-tone digits are dialed, when PTT, COs, and Auxiliary functions are active. Very useful for checking proper operation of all of those functions.

As repeater:

Use Control-C to exit the readinput program.

BACK to last     Menu



Reboot IRLP Computer

As root:
shutdown -r now

Also, as root:
use Control-Alt-Delete

Also see shutdown command and reboot, should I?

BACK to last     Menu



*Should I?

Some people like to brag that they haven't rebooted their IRLP box for x months or y years. Is this safe?

While Linux is very stable and you can run a system that long without rebooting, there is legitimate reason to reboot now and then. At 0300 every night, your node goes out and grabs updates from the servers. To use some of Dave Cameron's own words, "When shared libraries, like glibc are updated, the programs that use these libraries have to be restarted to apply the update. The easiest way to do this is to simply reboot the machine. I am not suggesting a reboot after every update, but boasting a 300 day uptime does not always boast good security." (Thanks for the clarification, Dave.) Restarting your node now and then will assure that any updates received will run. Also see Reboot IRLP Computer.

*Late note on this. I received a note from someone who hadn't rebooted his FC3 IRLP/EchoIRLP node for a long period and thought he would give it a try after reading the above paragraph. The node did not fully reload for him when it came back up. At this point, we don't know whether it had to do with the fact that he also had EchoIRLP on the system, or if it was just because it probably had lots of changes taking place due to lack of prior rebooting. A file may be corrupt or something. I'll clarify this if it is ever resolved.

Also know that there is NO support for running EchoIRLP from the IRLP installs team. You're on your own if you choose to run it.

DO backup your system now and then. You can copy the /home directory and all its contents to your Windows computer if you like, and/or you can run the backup_for_reinstall script. I do both.

BACK to last     Menu



Remote Root Login
Preventing Direct Login

It has been suggested that you should prevent direct remote login by user root when using port 22 for ssh. Instead, you should login as repeater and then su - root. To disable direct remote login to root, edit the /etc/ssh/sshd_config file. Change the line PermitRootLogin as below.

As root:
pico -w /etc/ssh/sshd_config

Drop down to line 36 (on mine) and find the line that might read:
#PermitRootLogin yes

That's how it reads in my file. Simply uncomment the line (remove the #) and change the yes to no. Then, Control O and Control X to save and exit pico. You'll need to restart sshd for it to take effect.

As root:
service sshd restart

/etc/init.d/sshd restart

or, just reboot the computer.

Note: If you disable remote root login, you will also disable your ability to login as root with WinSCP, which will hinder your ability to administer your node in some cases.

Also see SSHD Port Change

BACK to last     Menu



Restore From Backup

When/if you want to upgrade from say RH9 to FC3, you need to backup your node per the usual instructions. Make sure that you put a copy of the irlp_backup.tgz file on your Windows computer so it isn't lost during the new install.

Reinstalling your node software from the irlp_backup.tgz file can probably be done by using WinSCP to move the .tgz file from your Windows machine to the /tmp directory on the node computer, and then uncompressing the files. However, it is recommended that you follow the instructions on the new-install page instead. Locate the category that says "reinstall from a backup". Those instructions are supposed to be the latest available and designed to reinstall from a backup, or reinstall after upgrading the OS. Follow the instructions on that page. You will download the most up-do-date reinstall script from the IRLP servers and use it to properly restore the node software.

BACK to last     Menu



Screen Blanker/Saver

Control over the screen blanker can be done with the setterm command.

As root:
setterm -blank 5

This will set the blanker timeout at 5 minutes. A range of 0-60 is accepted, so substitute the number you prefer. Zero disables the blanker.

BACK to last     Menu



Script not working?
New script installed but doesn't work.

I discovered something recently that solved a few mysteries. After downloading a couple of new scripts from someone, I couldn't get them to run. Permissions and ownership were correct, they just wouldn't work. I might get a file not found, or bad interpreter error.

I use WinSCP and Ultra-Edit for looking at and editing files most of the time. I found that by adding a simple # comment line to one of the files and saving it made it work. I then took the # comment line back out and it still worked. WTF? The only thing I can figure is the old caveat that you hear from the old-timers is indeed correct. Stuff that comes through the Windows world can sometimes get modified in a way that is invisible without a hex-editor and fails to work afterward. When I loaded the script and added the comment, Ultra-Edit simply cleaned it up and then it worked. As an experiment to prove that point, I opened the second "broken" script with pico -w and resaved it (Control-O). I did not edit the file, just opened, resaved, exit. It worked. Note that just opening the file for inspection won't clean it up. You have to actually resave the file. That's why opening it in Ultra-Edit while looking for the error didn't fix it. I actually had to make a change so that the file would be rewritten. The same is accomplished in pico by Control-O without editing anything.

BACK to last     Menu



Shut Down IRLP Computer

As root:
shutdown -h now

Also see reboot command.

BACK to last     Menu



SSHD Port Change

The default sshd port (used to remotely access your node computer) is port 22. Port 22 is well known, and subject to unauthorized login attempts by all kinds of people trying to find an unprotected place to play around. I was advised when I got started to move the sshd port to some other port. I also discovered that my ISP is blocking port 22 for security reasons. By the way, it goes without saying, you should be using a secure password. Don't make it easy for someone to compromise your system.

As root:
CD /etc/ssh

pico -w sshd_config

Look for the line that says #Port 22. On mine, that's line 13.

Remove the # and change the 22 to something of your choosing, so it looks like:
Port 12345

Use Control-O to save the file and then Control-X to exit the pico editor.

The above change tells sshd to listen on port 12345 for connections.

Finally, restart sshd:
service sshd restart

/etc/init.d/sshd restart

Don't forget to change the port forwarding in your router to reflect the new port that needs to be forwarded to your node computer. If you don't, you won't make it in when you try to remotely administer your node.

More sage advice from K9DC:

Actually, you should just do a 'service sshd restart' command and then test it before disconnecting your current session.

The 'service sshd restart' only affects new sessions and will NOT disconnect your current session. So just in case it doesn't work (typo, router port forward not set up, etc) you have a way to correct it before locking yourself out. [we've all done it, the further away from your node you are, the more likely it is to happen <sigh>]

You can also list multiple ports if you need sshd to listen on more than one.

-Dave K9DC

To do multiple ports as Dave suggests above, edit the file to add extra port lines as below.
Port 22
Port 12345

Doing this would allow (for instance) blocking port 22 on your router while passing port 12345 to the node box for remote access. Port 22 could be used on your LAN and not change the configuration of programs like Putty and WinSCP.

BACK to last     Menu



su or su -
How to switch (set) users

The su command can be used to temporarily "become" another user. If you are logged in as repeater and need to do something as root, no need to exit and relog. Just su root. If you use the -, you have all rights of that user, as if you are that user. You'll log in and have access to everything in his home directory. Examples below.

As repeater:
su - root
Logs you in as root and loads the environment for user root.

As root:
su - repeater
Logs you in as repeater and loads the environment for user repeater.

To log out, simply type exit. This will take you back to where you came from (but isn't teleportation).

BACK to last     Menu



Tail Command
Monitor a log in realtime

The tail command reads the last 10 lines of a file. By adding a command line switch, it will continue to output new lines as they appear in realtime.

As repeater:
tail /home/irlp/log/messages
will read the last 10 lines of the file and then exit to prompt.

But, by adding a -f switch, you can watch the node's log file activity in realtime.

As repeater:
tail -f /home/irlp/log/messages

Use Control-C to exit the tail program.

More than 10 lines can be read by adding another command line switch.
tail -f -n20 /home/irlp/log/messages
will read the last 20 lines of the file and then keep running to read realtime input.

Other logs can be monitored the same way
(such as system log - as root: tail -f /var/log/messages)

In case you should need it, you can read the first 10 lines of a file with the head command, same syntax as above for reading more than 10 lines.
(As repeater: head -n20 /home/irlp/log/messages to read the first 20 lines of the log)

BACK to last     Menu



Timeout Timer Changes
And how to disable

There are two timeout timers to be concerned with. To change them, edit the appropriate file. A value of zero equals no timeout. Read the warning at the bottom of this section.

The node-to-node timer is defaulted to 240 seconds (4 minutes), and is located in

The node-to-reflector timeout is defaulted to 1200 seconds (20 minutes) in
Change the line that reads export REFLECT_TIMEOUT_VALUE=1200

Reload rc.irlp after you edit the file(s) so the change(s) will take effect immediately.
As root:

There's something to remember about the activity timeout timer during a node-to-node connection. Either side can timeout the connection (see notimeout function below). If your timer is set at 30 minutes, and the timer on the far end is set at 10 minutes, the shorter one will control the link, no matter what activity there is on the side of the longer one.

There are two other timers to be aware of in the system. Both are locked by the program author. The COs and PTT will time out at 4 and 5 minutes respectively if either of them is locked on. On my 4.03 IRLP installation, the COs timer also breaks the connection. There is a secondary timer that says the COs must go away for more than 1 second before it resets, according to "The Unofficial Manual". But on mine, it appears to be more like 5-10 seconds before you can reconnect. The PTT timer will drop the PTT line (your transmitter) when it times out, and reset when whatever is causing the PTT action goes away.

To disable the activity timeout timer for a specific connection to a reflector, you can put an entry in the custom_decode file to call that reflector with disabled timeout. Read the WARNING at the bottom of this section! The following line in the custom_decode file will connect to the 9250 reflector with no timeout using Touchtone #A.

if [ "$1" = "PA" ] ; then "$SCRIPT"/connect_to_reflector ref9250 notimeout ; exit 1 ; fi

You can also use the notimout option in your custom.crons file. To connect to the 9250 reflector with no activity timeout each morning at 0800, the line would look like:

0 8 * * * ("$SCRIPT"/connect_to_reflector ref9250 notimeout > /dev/null 2>&1)

If you want to use the notimeout function for specific node-to-node connection in your custom_decode or custom.crons file, you can use the call stn1234 notimeout command in place of the connect_to_reflector refxxxx notimeout command. Note, even though the far side station might have a timeout timer, the notimeout function disables it on both ends. Again, read the warning below.

As above, if you want to connect to node 1234 with no timeout using Touchtone #A, you could have an entry in custom_decode that looks like:

if [ "$1" = "PA" ] ; then "$SCRIPT"/call stn1234 notimeout ; exit 1 ; fi

See custom.crons for more detail on using crons.

WARNING! Do not connect to any node/reflector using the notimeout option without permission of the node/reflector owner! You could find yourself locked out.

BACK to last     Menu




Make sure node is disconnected.

As repeater (and demonstrating different ways to access the scripts folder):

Note the period at the beginning of that line.




BACK to last     Menu



Wave Files
Uploading Custom Wave Files To IRLP Server

Note: Upload your link-on/off files to the /tmp directory or have them on a floppy disk on the node computer. They MUST be the proper format, see detail in "What to do after Installation" instructions.

As root:

Audio files will be automatically deleted from the /tmp directory after upload. Be sure to keep a backup on the floppy, or elsewhere.

BACK to last     Menu



WinSCP, Putty, What's The Fuss?

WinSCP is a godsend for those of us coming into this from the world of Bill Gates. If you're running an IRLP Node on a LAN with your Windows based home computer(s), you will love it. WinSCP is a split screen file manager that uses SSH to communicate with your node and allows you to do file management on your node from Windows. Download and install it on your Windows machine. To copy a file from one computer to the other, just double click on it. To edit a file with your default editor, right click the file and click the Edit button.

While you're at it, you might as well get Putty, if you haven't already. Putty allows you to be at your Windows computer and remotely login to your node computer (again using SSH), as if you were sitting right in front of it. Putty.exe is the whole thing. There isn't any installation involved. Just put it in a directory, make a shortcut to it, and run it. You'll need to configure it similar to WinSCP.

At this point, my original instructions said to go to the new-installs section and click on the link that says "reinstall from a backup". The early part of that document tells you how to setup WinSCP. Install it with the Commander Interface so you can see both computers at the same time.

Instead of sending you there, I've pulled those instructions into this document, captured new screen-shots, and modified them here and there for clarity. Feel free to use the original instructions, if you like, or continue below.

Except for the images, most of what's below is copied directly from the above mentioned document. I've clipped out the "get it from here" links, because they link to an older version of the program and no longer work. I've also taken the liberty of making minor wording changes and additions for clarity.

Once you have the WinSCPsetup program on your windows computer, double click it and let it install. When you start WinSCP, you should see a screen like this:

WinSCP Pre-Login Screen Shot

If your node is behind the same firewall as your windows computer, the host name you enter will be the actual IP address of the network card in the node. The IP address can be seen by logging into the node (as root or repeater) and typing:

/sbin/ifconfig eth0

The line you're looking for should read something like:

inet addr: Bcast: Mask:

In the example above, is the node's LAN IP address, and will be used for access by WinSCP (or Putty) from behind the same firewall.

If your node is behind a separate firewall from your Windows computer, you will need to know the public IP address. You can find that by logging into the node (as root or repeater) and typing:

telnet server3.irlp.net 10000

The IP address you receive from either method above must be entered in the host name field in WinSCP and change the port number to whatever you're using for SSH. Type in repeater as your user name. Put your password for user repeater in the Password field. You can also use root and root's password if you don’t know your repeater password. See passwd to install a repeater password if you haven't done it yet. In reality, while I usually login as repeater for safety, I configure both a root and repeater login for WinSCP so that I can work on whatever I want remotely. Use repeater login for routine node maintenance. Before you click on login, save the configuration so you don't have to do it again the next time you use it.

The opening screen might look something like this after you configure a repeater and root user login.

WinSCP Login Screen Shot

In this case, I have two nodes in the configuration, one is my own, inside the LAN, and a second one in another city.

When you click login and a connection is made with your node, you may get a Windows pop-up about adding the "key". Click Yes. This will happen for any first time login to a specific address.

Double clicking on any of them establishes the connection and will open to show you something like below (shrunk for web display). When you're logged in, you will see your local computer on the left side, and your node on the right (in Commander mode). You should use Windows Explorer to make a directory for your IRLP stuff on your Windows machine. In WinSCP, navigate to that directory (double click it) so you can see inside it on the left part of the WinSCP window. Then, save that session by going up to the blue floppy disk icon on the right end of the tool bar and clicking it. You may also use Alt-S for session, and choose Save Session. By saving with the same configuration name, the window will open up to the same directories the next time you run the program.

WinSCP Open Screen Shot

The Putty configuration is similar to WinSCP, except that you only configure once per address. You'll login as repeater or root, just as you would from the local console.

When you load the program for the first time, you should see something similar to the screen below, with only the Default Settings entry showing. Put the IP address for the node in the Host Name box, change the port number to whatever you're using for SSH, give it a name (such as the node number) in the Saved Sessions box, and then click Save.

Putty screen shot

Double click the name in the lower box and it will open to a new DOS-like window. When it establishes connection, you'll be greeted with a login prompt, just like on the console. When done, logoff the far end the same as you would if you were at the console, using the logout or exit command. The window should close, but on my system, the window only closes as it should part of the time. If it doesn't close on its own, just hit the X to close it.

BACK to last     Menu



[ 25.08.2005 9:28 ] IRLP IRLP- (. ), : AG0N New

URL: aprs.qrz.ru, ehant.qrz.ru, yl2rmk.qrz.ru, ua1ati.qrz.ru, ut7izd.qrz.ru, ut2hi.qrz.ru, ra3is.qrz.ru, r3i.qrz.ru, r3r.ru, amsat.qrz.ru, vhf.qrz.ru, vhfdx.ru, ra3apw.qrz.ru, oldradio.qrz.ru, rc3c.ru,
echolink.ru © 2003-2017, All rights reserved
: R2AR * SKYPE: R2AR, RC3C ICQ: ICQ12605842, EchoLink: #2102, #53698 SKYPE: RC3C
: & qrz.ru, .
  ,         RC3C  eQSL.cc :: World eLog service  Log UR5EQF ::     UR5EQF