Home Category Blog
How do I remove EchoIRLP from my node? PDF Print
Written by Administrator   
Thursday, 19 August 2010 05:48

The install process for EchoIRLP makes some modifications to a couple of the core IRLP files and also creates and populates several directories with it's binaries and configuration files.  By reversing the modifications made by the EchoIRLP installer, and removing the EchoIRLP support files, you can bring your node back to it's original (pure IRLP) state.  During the install of EchoIRLP, the following files were modified:

 

  • /home/irlp/custom/rc.irlp

The following code is added:

# source the EchoIRLP env

if [ -f /home/EchoIRLP/custom/echo_environment ] ; then

. /home/EchoIRLP/custom/echo_environment

fi

echo "Starting the Bridge..."

if ps -A | egrep 'tbd$' > /dev/null 2>&1; then

/etc/init.d/theBridge restart

else

/etc/init.d/theBridge start

fi

if [ -x "$ECHO_SCRIPT/echo_enable" ] ; then

echo -n "Enabling connections to the EchoLink Node..."

/bin/su - -c "$ECHO_SCRIPT/echo_enable" repeater &>/dev/null

echo "done!"

fi

The relavent EchoIRLP code in your rc.irlp file may differ somewhat from the above but it should be apparent what code was added by your version of the EchoIRLP installer script.  Before you start modifying it, make a backup of your current rc.irlp file! Once you've done that, you can proceed with manually removing the EchoIRLP code within it.  Any stanzas referring to echo_environment, EchoIRLP, tbd, theBridge, echo_enable, $ECHO_SCRIPT, etc. were added by the EchoIRLP installer and need to be removed.  Since the installer probably made a backup of your rc.irlp file before it modified it, you should be able to find and compare that backed up version with the current one to see what was added.  Just keep in mind that some other add-ons may have also modified your rc.irlp file since you installed EchoIRLP so you shouldn't just copy that backed up version over the current one.  If you do, you risk breaking the other add-ons which may rely on the changes they made to it.  The backup file for my rc.irlp is named, "rc.irlp.bak" and is located within the /home/irlp/custom directory.  Yours is probably similar unless you changed or removed it.  By comparing the current version to the backup, it should be obvious which things were added by the EchoIRLP installer.  If you can't find a backed up version of your rc.irlp file for whatever reason, you'll just have to carefully go through and remove all traces of the EchoIRLP code.  Luckily it's fairly easy to spot and it's usually at or near the end of the file since the changes simply get appended to the end during the EchoIRLP install process.

 

  • /home/irlp/custom/custom_decode

The following code is added:

# If you change the EchoIRLP prefix, you must also change "num" below to the number of digits in the prefix.

eval `echo $1 | awk -v num=1 '{

print "PRE="substr($1,1,num);

print "NODE="substr($1,(num)+1,length($1))}'`

# call echolink conferences using pound node method

if [ "$PRE" = "P" ]; then

"$ECHO_SCRIPT"/echo_call $NODE &

exit 1

fi

The relavent EchoIRLP code in your custom_decode file should be very similar to the above. Again, before you start modifying it, make a backup of your current custom_decode file! Once you've done that, you can proceed with manually removing the EchoIRLP code within it.  Any stanzas referring to EchoIRLP, $ECHO_SCRIPT, echo_call, etc. need to be removed.  The additions made by the EchoIRLP installer will probably be near the bottom of the file unless you have added lots of things to your custom_decode file since installing EchoIRLP.

 

  • /home/irlp/custom/custom_on
  • /home/irlp/custom/custom_off

The following code is added:

# Added for EchoIRLP status page update

if [ -x "$ECHO_SCRIPT/echo_status" ] ; then

"$ECHO_SCRIPT/echo_status"

fi

Remove that code from both of the custom_on and custom_off files.

 

 

 

 

  • /home/irlp/custom/environment

The environment file will have an entry similar to the following, probably at or near the bottom of the file:

if [ -x /home/EchoIRLP/custom/echo_environment ] ; then

source /home/EchoIRLP/custom/echo_environment

fi

That code should be removed from the environment file as it will no longer be applicable.

 

You will also need to remove EchoIRLP's config from the applicable boot-up runlevel(s).  To do this, issue the following commands as root:

1. /etc/init.d/tbd stop (or for Ubuntu do, "/etc/init.d/theBridge stop") - this will stop the EchoIRLP process

2. chkconfig --del tbd (or for Ubuntu do, "update-rc.d -f theBridge remove") - this will remove the system startup links to the EchoIRLP software

Now proceed with these final steps to completely remove EchoIRLP from your IRLP node:

Completely remove the /home/EchoIRLP/ directory.

This directory contains most of the core EchoIRLP files.  This directory in it's entirety can safely be removed.

Remove the /etc/init.d/tbd or /etc/init.d/thebridge init script. (depending on whether it's Ubuntu)

It will probably be named, "tbd" but for Ubuntu installs, it will probably be, "theBridge."  Basically you just want to locate the init script for theBridge and make sure it's been removed.

Remove the tbd.conf and tbd.conf.sample files from the /usr/local/etc/ directory.

More than likely they will be the only files in /usr/local/etc/.  Simply delete them.

Remove all tbd* files from the /usr/local/bin/ directory.

These are mostly symbolic links to the actual files that were located in the /home/EchoIRLP/tbd/ directory but since we removed the /home/EchoIRLP/ directory altogether, these are now broken sym-links and should be removed for completeness.

Remove any thebridge and tbdcnv files and directories from the /usr/src/ directory.

The EchoIRLP build process leaves some of these files in the /usr/src/ directory.  They should be removed.

That's it!  Those steps will yield you a pure IRLP Node.  As a final step, and just to make sure the system comes up as expected, a node reboot would be recommended at this point.  Take note of any irregularities during the boot-up process.  There should be none.

 

 

 
Last Updated on Sunday, 12 December 2010 22:46
 
How do I change my node's hostname? PDF Print
Written by Administrator   
Tuesday, 17 August 2010 12:04

The default install of Linux will usually set the hostname to some generic value such as, "localhost" or something having to do with the name of the distribution.  Some may want to give their node a more meaningful name.  Although there's no functional advantage to changing it, at least for most IRLP nodes, some node owners opt to do it anyway.  One user advantage of doing it is in the case that you own or administer several nodes.  It becomes much easier if you can quickly look at the command prompt and instantly know with which node you are interacting.  To change the node's hostname simply edit the hostname variable within the /etc/sysconfig/network file.  On Ubuntu systems, simply change it within the /etc/hostname file.  To make the change take affect immediately, you can restart the network.  On Ubuntu systems, the command, "sudo hostname <name>" will suffice.  In either case, a reboot will also accomplish the task.  Once you change your hostname, you need to make sure it resolves or more correctly, reverse maps to something.  The easiest way to accomplish this is to edit the /etc/hosts file and make sure you have a line that tells your node what it's new name reverse maps to.  Since 127.0.0.1 is the host's local loopback address, we can map the new hostname to that address with the addition of the following line:

127.0.0.1     localhost     <name>

Obviously replace <name> with what you actually named it.  For example, on one of my nodes, I have:

127.0.0.1   localhost   stnxxxx

 

After applying the changes and restarting the network, you can (and should) test to make sure the new name is properly mapped to the host address.  The ping utility will come in handy for this.  Simply ping the new name and you should get responses back.  If you do, you're set!  If not, go back and verify that your /etc/hosts file is correct and fix it if necessary.  To stop the pings, use CTRL-c and the ping utility will exit with some statistics.  Here's an example of a working configuration's responses to 4 pings:

 

repeater@stnxxxx:~$ ping stnxxxx

PING stnxxxx (127.0.0.1) 56(84) bytes of data.

64 bytes from stnxxxx (127.0.0.1): icmp_seq=1 ttl=64 time=0.030 ms

64 bytes from stnxxxx (127.0.0.1): icmp_seq=2 ttl=64 time=0.017 ms

64 bytes from stnxxxx (127.0.0.1): icmp_seq=3 ttl=64 time=0.016 ms

64 bytes from stnxxxx (127.0.0.1): icmp_seq=4 ttl=64 time=0.017 ms

 

--- stnxxxx ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 2997ms

rtt min/avg/max/mdev = 0.016/0.020/0.030/0.005 ms

 

 

 
Last Updated on Friday, 20 August 2010 09:57
 
Node Owner's FAQ PDF Print
Written by Administrator   
Tuesday, 17 August 2010 11:46

As a new IRLP Node owner, you will undoubtedly have some questions as you become more familiar with the operation of your node and the network as a whole.  The Official IRLP Website has a node owner's FAQ available to help answer some of the questions you will have.  It can be accessed here:

http://www.irlp.net/faq_owners.html
Last Updated on Friday, 20 August 2010 09:58
 
How do I change the SSH port on my IRLP Node? PDF Print
Written by Administrator   
Tuesday, 04 August 2009 07:33

Most IRLP Nodes run an OpenSSH Server which provides remote command shell access to them.  It is very handy and highly recommended due to its ease of use and secure implementation.  That being said, any remote access methods introduce a certain amount of risk, even if the methods used are considered, "secure."  There are things we can do to decrease that risk.  One of them involves changing the default port on which the SSH server listens for connections.  Since this is a very easy thing to accomplish and only takes a minute or so to do, it's a step I recommend to everyone who runs an SSH server.  The following steps will cause your server to stop listening for SSH connections on the default port (TCP port 22), and cause it to start listening for connections on some other port of your choosing:

  1. Login to your IRLP Node and become root (directly login as root or su as necessary).
  2. Change to the SSH configuration files directory by doing, "cd /etc/ssh" at the command prompt.
  3. Make a backup of the original sshd_config file by doing, "cp sshd_config sshd_config_orig" at the command prompt.
  4. Open the sshd_config file in your text editor (use vim, pico, etc.) and find the line that starts with, "Port" near the top of the file.  It may be commented out in some versions in which case the default port of 22 is used by the server.  In any case the, "Port" directive needs to be un-commented and have a number other than 22 after it (must also be in the range of 1-65535).  The number you specify will be the new port on which the server will listen for connections.  For example, if you wanted the SSH server to listen on port 2022, you would make sure the line reads:

    5. Port 2022

  5. Save the modified sshd_config file.
  6. Re-load the SSH server by doing, "/etc/init.d/ssh reload" (It may be /etc/init.d/sshd or similar - just check for the init script within your /etc/init.d/ directory if you get a, "file not found" type error.)
  7. Once you have reloaded the SSH server, it will be listening on the new port.  Your current shell session over SSH will still be active (assuming you are doing this remotely over SSH) even though the server is now listening on the new port.  Once you close the current connection, there will be no future connections accepted on the old default port.  To test it, simply logout and then try to log back in again over SSH.  Unless you tell your SSH client to connect to the new port, your connection attempt will be ignored by the SSH server.

 

There are some other things you may want to add to your SSH server's config file which will enhance connection robustness and increase performance over slow and/or latent connections.  I *always* add the following lines to my sshd_config file on all my nodes and servers:

# compress data over connection
Compression yes

# keep connection alive
ClientAliveInterval 60

The first one enables data compression.  There's never a reason not to run compression.  The CPU overhead is so minimal and the performance of the data transfer so great, that the choice should be obvious!  I don't know why it's not the default - maybe it is...

The second one helps keep the session from closing due to periods of inactivity.  I don't want the connection to close until I'm ready to close it.  This helps in that regard.

These simple steps should increase performance and will effectively hide your SSH server from the mindless SSH scanner scripts that are constantly being run across the 'Net looking for possible targets.
Last Updated on Friday, 20 August 2010 09:59
 
How do I update my IRLP Node? PDF Print
Written by Administrator   
Tuesday, 04 August 2009 21:52

IRLP software updates happen automatically overnight, as long as your node is not connected to a node or reflector when the software update software executes.  Some IRLP node owners don't know it but these updates can also be requested manually, at any time, by doing the following:

  1. Login to your node as user repeater.
  2. Type, "decode 73", press enter and wait for the node to disconnect from whatever node or reflector it is connected to.
  3. Type, "update files" and press enter.  Your IRLP Node will verify with the server that it has the latest software using rsync.  If there are any files which have been updated on the server, then it will automatically download them.  When it finishes verifying/downloading, your IRLP software will be up-do-date.
  4. There's no need to reboot as the updates are applied straight away.

During the update process, you will probably see a message to the affect of, "Client is very old version of rsync, upgrade recommended."  This can be safely ignored.  The version of rsync that ships with IRLP is an older version for compatibility reasons, but is fully functional.
Last Updated on Friday, 20 August 2010 09:59
 
More Articles...
«StartPrev123NextEnd»

Page 1 of 3
 

Advertisements