ISDN Cause Codes

August 9, 2013

Cause No. 0
This is usually given by the router when none of the other codes apply. This cause usually occurs in the same type of situations as cause 1, cause 88, and cause 100.

Cause No. l – Unallocated (unassigned) number.
This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).
What it usually means:

The SPIDS may be incorrectly entered in the router or the Telco switch, giving a SPID failure in the router logs.
The ISDN phone number being dialed by the router is invalid and the telco switch cannot locate the number to complete the call, as it is invalid.
On long distance calls, the call cannot be properly routed to its destination.

Cause No. 2 – No route to specified transit network (national use).
This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network not serve the equipment which is sending this cause.

Cause No. 3 – No route to destination.
This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network dependent basis.

Cause No. 4 – send special information tone.
This cause indicates that the called party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party.

Cause No. 5 – misdialed trunk prefix (national use).
This cause indicates the erroneous inclusion of a trunk prefix in the called party number. This number is to sniped from the dialed number being sent to the network by the customer premises equipment.

Cause No. 6 – channel unacceptable.
This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call.

Cause No. 7 – call awarded. being delivered in an established channel.
This cause indicates that the user has been awarded the incoming call and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode x.25 virtual calls).

Cause No. 8 – preemption.
This cause indicates the call is being preempted.

Cause No. 9 – preemption – circuit reserved for reuse.
This cause indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange.

Cause No. 16 – normal call clearing.
This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.
What it means:
This could be almost anything; it is the vaguest of the cause codes. The call comes down normally, but the reasons for it could be:

Bad username or password
Router’s settings do not match what is expected by the remote end.
Telephone line problems.
Hung session on remote end.

Cause No. 17 – user busy.
This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.
What is means:
Calling end is busy.

Cause No. 18 – no user responding.
This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.
What it means:
The equipment on the other end does not answer the call. Usually this is a misconfiguration on the equipment being called.

Cause No. 19 – no answer from user (user alerted).
This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note – This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.

Cause No. 20 – subscriber absent.
This cause value is used when a mobile station has logged off. Radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable at any user-network interface.

Cause No. 21 – call rejected.
This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.
What it means:
This is usually a telco issue. The call never reaches the final destination, which can be caused by a bad switch translation, or a misconfiguration on the equipment being called.

Cause No. 22 – number changed.
This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this cause, cause no. 1, unallocated (unassigned) number shall be used.

Cause No. 26 – non-selected user clearing.
This cause indicates that the user has not been awarded the incoming call.

Cause No. 27 – destination out of order.
This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term “not functioning correctly” indicates that a signal message was unable to be delivered to the remote party; e.g., a physical layer or data link layer failure at the remote party or user equipment off-line.

Cause No. 28 – invalid number format (address incomplete).
This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.

Cause No. 29 – facilities rejected.
This cause is returned when a supplementary service requested by the user cannot be provide by the network.

Cause No. 30 – response to STATUS INQUIRY.
This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS INQUIRY.

Cause No. 31 – normal. unspecified.
This cause is used to report a normal event only when no other cause in the normal class applies.

Cause No. 34 – no circuit/channel available.
This cause indicates that there is no appropriate circuit/channel presently available to handle the call.
What it means:
There is no place on the Public Telephone network to place the call; the call never gets to its destiation. This is usually a temporary problem.

Cause No. 35 – Call Queued.

Cause No. 38 – network out of order.
This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time e.g., immediately re-attempting the call is not likely to be successful.

Cause No. 39 – permanent frame mode connection out-of-service.
This cause is included in a STATUS message to indicate that a permanently established frame mode connection is out-of-service (e.g. due to equipment or section failure)

Cause No. 40 – permanent frame mode connection operational.
This cause is included in a STATUS message to indicate that a permanently established frame mode connection is operational and capable of carrying user information.

Cause No. 41 – temporary failure.

This cause indicates that the network is not functioning correctly and that the condition is no likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately.
What it means:
This means that there is a temporary failure at the physical layer on the ISDN network. If you remove the ISDN cable from the Netopia, you would see this. It’s usually temporary.

Cause No. 42 – switching equipment congestion.
This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic.
What it means:
Just too much going on at this point on the ISDN network to get the call through to its destination.

Cause No. 43 – access information discarded.
This cause indicates that the network could not deliver access information to the remote user as requested. i.e., user-to-user information, low layer compatibility, high layer compatibility or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic.

Cause No. 44 – requested circuit/channel not available.
This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.

Cause No. 46 – precedence call blocked.
This cause indicates that there are no predictable circuits or that the called user is busy with a call of equal or higher preventable level.

Cause No. 47 – resource unavailable, unspecified.
This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.

Cause No. 49 – Quality of Service not available.
This cause is used to report that the requested Quality of Service, as defined in Recommendation X.213. cannot be provided (e.g., throughput of transit delay cannot be supported).

Cause No. 50 – requested facility not subscribed.
This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause but the user is not authorized to use.
What it means:
The switch looks at the number being dialed and thinks it is for another service rather than ISDN. If the phone number is put in the correct format, the call should be placed properly. There are no standards for this, all Telcos have their own system for programming the number formats that the switches will recognize. Some systems want to see 7 digits, some 10, and others 11.

Cause No. 52 – outgoing calls barred.

Cause No. 53 – outgoing calls barred within CUG.
This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call. Outgoing calls are not allowed for this member of the CUG.

Cause No. 54 – incoming calls barred

Cause No. 55 – incoming calls barred within CUG.
This cause indicates that although the calling party is a member of the CUG for the incoming CUG call. Incoming calls are not allowed for this member of the CUG.

Cause No. 57 – bearer capability not authorized.
This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use.

Cause No. 58 – bearer capability not presently available.
This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time.

Cause No. 62 – inconsistency in outgoing information element.
This cause indicates an inconsistency in the designated outgoing access information and subscriber class.

Cause No. 63 – service or option not available. unspecified.
This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.

Cause No. 65 – bearer capability not implemented.
This cause indicates that the equipment sending this cause does not support the bearer capability requested.
What it means:

In most cases, the number being called is not an ISDN number but an analog destination.
The equipment is dialing at a faster rate than the circuitry allows, for example, dialing at 64K when only 56K is supported.

Cause No. 66 – channel type not implemented.
This cause indicates that the equipment sending this cause does not support the channel type requested.

Cause No. 69 – requested facility not implemented.
This cause indicates that the equipment sending this cause does not support the requested supplementary services.

Cause No. 70 – only restricted digital information bearer capability is available.
This cause indicates that the calling party has requested an unrestricted bearer service but the equipment sending this cause only supports the restricted version of the requested bearer capability.

Cause No. 79 – service or option not implemented unspecified.
This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.

Cause No. 81 – invalid call reference value.
This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface.

Cause No. 82 – identified channel does not exist.
This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call. For example, if a user has subscribed to those channels on a primary rate interface numbered from l to 12 and the user equipment or the network attempts to use channels 3 through 23, this cause is generated.

Cause No. 83 – a suspended call exists, but this call identify does not. This cause indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended call(s).

Cause No. 84 – call identity in use.
This cause indicates that the network has received a call suspended request containing a call identity (including the null call identity) which is already in use for a suspended call within the domain of interfaces over which the call might be resumed.

Cause No. 85 – no call suspended.
This cause indicates that the network has received a call resume request containing a call identity information element which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed.

Cause No. 86 – call having the requested call identity has been cleared.
This cause indicates that the network has received a call resume request containing a call identity information element indicating a suspended call that has in the meantime been cleared while suspended (either by network time-out or by the remote user).

Cause No. 87 – user not a member of CUG.
This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG or that the calling user is an ordinary subscriber calling a CUG subscriber.

Cause No. 88 – incompatible destination.
This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility. high layer compatibility or other compatibility attributes (e.g., data rate) which cannot be accommodated.
What it means:

This usually means that the Number To Dial in the Connection Profile is in the wrong format. You may need to dial a 10 or 11 digit number, or dial a 9 in front of the number if it is a Centrex line.
This problem may also give a Cause 111.
Dialing at the wrong line speed can also give this Cause.

Cause No. 90 – non-existent CUG.
This cause indicates that the specified CUG does not exist.

Cause No. 91 – invalid transit network selection (national use).
This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex C/Q.931

Cause No. 95 – invalid message, unspecified.
This cause is used to report an invalid message event only when no other cause in the invalid message class applies.

Cause No. 96 – mandatory information element is missing.
This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed.
What it means:
This is rarely seen in North America but usually means that the number that is being dialed is in the wrong format, (similar to cause 88). Some part of the format being used is not understood by either the remote side equipment or the switching equipment between the source and destination of the call.

Cause No. 97 – message type non-existent or not implemented.
This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined of defined but not implemented by the equipment sending this cause.

Cause No. 98 – message not compatible with call state or message type non-existent.
This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state.

Cause No. 99 – Information element / parameter non-existent or not implemented.
This cause indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the information element(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.

Cause No. 100 – Invalid information element contents.
This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment sending this cause.
What it means:
Like cause 1 and cause 88, this usually indicates that the ISDN number being dialed is in a format that is not understood by the equipment processing the call. SPIDs will sometimes fail to initialize with a Cause 100, or a call will fail with this cause.

Cause No. 101 – message not compatible with call state.
This cause indicates that a message has been received which is incompatible with the call state.

Cause No. 102 – recovery on timer expiry.
This cause indicates that a procedure has been initiated by the expiration of a timer in association with error handling procedures.
What it means:
This is seen in situations where ACO (Alternate Call Offering) is being used. With this type of call pre-emption, the Telco switch operates a timer. For example, when an analog call is placed to a Netopia router that has two B Data Channels in place, the router relinquishes the second channel, but if it doesn’t happen in the time allotted by the switch programming, the call will not ring through and will be discarded by the switch.

Cause No. 103 – parameter non-existent or not implemented – passed on (national use).
This cause indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending this cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed unchanged.

Cause No. 110 – message with unrecognized parameter discarded.
This cause indicates that the equipment sending this cause has discarded a received message which includes a parameter that is not recognized.

Cause No. 111 – protocol error, unspecified.
This cause is used to report a protocol error event only when no other cause in the protocol error class applies.

Cause No. 127 – Intel-working, unspecified.
This cause indicates that an interworking call (usually a call to 5W56 service) has ended.

Notes about Cause Codes over 128
Cause code values of 128 and higher aren’t sent over the network. A terminal displaying a value 128 or higher and claiming it is a cause code arguably has a bug or is implementing some proprietary diagnostic code (not necessarily bad). Some commendation has cause codes listed with numbers higher than 128, but at this time they are proprietary in nature.

The PRI equipment vendors are the most likely to use these codes as they have been using proprietary messages in the facilities data link for some time now (there is an as yet undefined area in the FDL which is big enough to carry small datagrams or messages). It is typically used to pass proprietary control or maintenance messages between multiplexers.

Advertisements

Check and Repair MySQL Databases

August 2, 2013

To check and repair all MySQL databases, you need to run this command from the CLI.

mysqlcheck -u root -p --auto-repair --check \
--optimize --all-databases

After that it will show you a screen if the tables are up to date, ok, etc.


A parent’s guide to Linux Web filtering

November 7, 2008

Linux.com

Everything Linux and Open Source

A parent’s guide to Linux Web filtering

July 01, 2004 (8:00:00 AM) –  4 years, 4 months ago

By: Joe Bolin

Having converted quite a few people to the world of GNU/Linux, I am often asked by parents, “Can I set up parental Web filters for my children using Linux?” The answer is yes, and here’s how.

A Web filter is a software that can filter the type of content a Web browser displays. The filter checks the content of a Web page against a set of rules and replaces any unwanted content with an alternative Web page, usually an “Access Denied” page. The type of content to be filtered is usually controlled by a systems administrator or a parent. Web filters are used in schools, libraries, and homes to safeguard children from obscene content on the Internet.

Before you begin, you should be familiar with some basic networking concepts:

  • A server, as in “Web server,” is nothing more than an application that runs on a computer and listens for incoming requests. It sends back, or serves, information to the source that requested the information. This information can be anything from Web pages to databases. Each server communicates through the use of an IP address and a port number.
  • Ports are logical addresses that applications on a computer use in a way similar to how we use phone numbers. Each server program must have a unique port that it uses for communications.
  • Every computer connected to the Internet has both an external IP (Internet Protocol) address, usually assigned by an Internet service provider, and an internal address of 127.0.0.1. The internal address allows the computer to “listen” and “talk” to itself and is referred to as the loopback address. Normally a server is set up to accept requests from other computers on the Internet by listening on its external address. Since this can present a security risk for our single computer, we will use the loopback address instead. This will cause our server to only listen for requests from the computer that the server resides on.
  • A firewall is an application that controls the types of communication your computer can send and receive. GNU/Linux has an excellent firewall called netfilter/iptables, or simply iptables, built right into the kernel, which we will make use of to redirect users’ Web surfing through our Web filter.

Getting the software

The only software you need to set up parental filters under GNU/Linux is iptables, DansGuardian, and Squid.

DansGuardian is the actual filtering software. It supports phrase matching, which allow you to block out Web sites that contain certain phrases or words; PICS filtering, which blocks content that’s been labeled as possibly objectionable material by the creator of the Web site; URL filtering, to block content from specific sites that are known to contain offensive material; and blacklists, or lists of sites that contain content you want to block. Blacklists usually come from third parties, though you can create and maintain your own.

Squid is a Web proxy server that acts as a middleman between your computer and the Internet. You need a proxy server because DansGuardian isn’t able to fetch Web pages by itself. We’ll configure Squid as a transparent proxy, meaning we’ll hijack network traffic and redirect it to a new destination — our filter program, in this case — without the need for the user to know that it is happening.

Most modern distribution have packaged versions of Squid and DansGuardian available. If yours doesn’t then you will need to install them from source code. Both the Squid and DansGuardian Web sites have complete instructions for how to compile and install the programs from source.

Iptables is the firewall management tool used with the 2.4.x and higher kernels. Most modern distributions provide iptables. If yours doesn’t, you will need to compile a new kernel and enable iptables, which is beyond the scope of this article (and probably beyond the abilities of most parents). You’d probably be better off upgrading to a newer Linux distribution.

Configuring Squid

The default location for the Squid configuration file on most systems is /etc/squid/squid.conf. While most of the default settings for Squid are all right for our usage, you will need to edit the configuration file just a bit.

You will need to become the root user in order to make the changes and issue the commands shown in this article. You can do this by either logging in as root or with the su command.

Add or edit the following line to have Squid listen only on the loopback device on port 3128. This will cause Squid to act only as a proxy server for this computer and assigns it a specific port number to listen on:

http_port 127.0.0.1:3128

To configure Squid as a transparent proxy, add the following lines to squid.conf:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Your system should have created a user and a group named squid when you installed Squid. If it didn’t, you should create them yourself by using the following two commands from the command line:

groupadd -r squid
useradd -g squid -d /var/spool/squid -s /bin/false -r squid

Since Squid is normally started by the system and run as root, you need to add the next two lines to /etc/squid/squid.conf in order to make Squid run with squid‘s user and group IDs:

cache_effective_user squid
cache_effective_group squid

We will later use this to identify Squid to our firewall. Then we will allow the user squid to access the Internet while we redirect all other Web traffic through our filter.

Configuring DansGuardian

Our next step is to configure DansGuardian. The default location, on most systems, for the configuration files is /etc/dansguardian/dansguardian.conf. Once again, most of the default values are fine, but we need to make a few changes.

First, add or edit the following line to make the filter use HTML templates, which are static Web pages that our filter will use to display the “Access Denied” page instead of the inappropriate sites. Using HTML templates keeps us from having to set up a Web server to display the “Access Denied” information.

reportinglevel = 3

Next, add or edit the following lines to make DansGuardian listen on the loopback address and port 8080:

filterip = 127.0.0.1
filterport = 8080

Add or edit the following line to tell DansGuardian which address and port that Squid is listening on. This enables our filter to fetch the requested Web content through the proxy.

proxyip = 127.0.0.1
proxyport = 3128

Again, to keep your filter from running as root you need to change the user that it will run as. For simplicity, we will reuse the user and group that we previously set up for Squid. Add or edit the following to make DansGuardian run with UID and GID of squid:

daemonuser = 'squid'
daemongroup = 'squid'

While DansGuardian provides an excellent filter all by itself, you may want to exercise further control over the Web filtering by editing the other files in the /etc/dansguardian directory that contain external blacklists. Blacklists from squidGuard and URLBlacklist work perfectly with DansGuardian. Each file contains a brief explanation for its contents to make configuration easier.

Putting it in action

Once you have Squid and DansGuardian set up, the final step is to implement a transparent proxy using iptables. Use the following commands at the command line to add rules to the firewall to allow the user squid to access both the Internet and the Squid proxy we set up.

iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --uid-owner squid -j ACCEPT

iptables -t nat -A OUTPUT -p tcp --dport 3128 -m owner --uid-owner squid -j ACCEPT

If you want a user to be exempt from filtering — a parent, for example — issue the following command. Replace EXEMPT_USER with the username that you wish to exempt from filtering:

iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --uid-owner EXEMPT_USER -j ACCEPT

The next command redirects Internet traffic from all users, other than squid and any exempt users, to the filter on port 8080:

iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 8080

Since we have a proxy server set up, a user could configure a Web browser to bypass the filter and access the proxy directly. The Squid proxy is listening for requests from the computer, and it doesn’t care which user sends the request. We could set up our firewall to deny all access to the proxy except from our filter, but let’s be a little sneakier. Let’s set it up so that direct requests to the Squid proxy server, except from our filter, get redirected through the filter. To do this, use the following command:

iptables -t nat -A OUTPUT -p tcp --dport 3128 -j REDIRECT --to-ports 8080

Some systems, such as MandrakeLinux, utilize an application called Shorewall to manage firewall rules. For these systems, place the above firewall rules in /etc/shorewall/start, to use the filtering when Shorewall starts, and in /etc/shorewall/stop, to make them stick if you should stop Shorewall for some reason. To implement the new rules simply restart Shorewall using the following command:

service shorewall restart

For systems using Shorewall, your firewall rules are set. For all other systems, you’ll need to perform the next two steps in order to get the new firewall rules started at boot time. Issue the following command to save your firewall rules:

iptables-save > /etc/sysconfig/iptables

Now issue the following to make sure iptables is started at boot time and to start the iptables firewall:

chkconfig iptables on
service iptables restart

You may also need to make sure that DansGuardian and Squid get started at boot by using the following two commands:

chkconfig squid on
chkconfig dansguardian on

To get the filtering started, you can now enter the following commands:

service squid restart
service dansguardian restart

Access Denied Thumbnail

The “Access Denied” screen – click to enlarge

Now when users enter a forbidden Web address they will be presented with an “Access Denied” page instead of the offending site. You can customize the look of the “Access Denied” page by editing the template.html file in the appropriate language section located in /etc/dansguardian/languages.

Final thoughts

While the setup discussed in this article is intended for use on a single computer, this method of Web filtering can be applied to a wide range of scenarios. These tools can be easily and successfully implemented on a small home network, a large business infrastructure, or any environment that needs to comply with the Children’s Internet Protection Act.

Bear in mind that Web filtering software of any kind is not 100% failsafe, nor is it a substitute for parental supervision. Along with installing filtering software, educate yourself and your children about the Internet.

Read in the original layout at: http://www.linux.com/articles/113733


CentOS 4 Install Yum

July 15, 2008

rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/sqlite-3.3.6-2.i386.rpm
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-sqlite-1.1.7-1.2.1.i386.rpm
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-elementtree-1.2.6-5.el4.centos.i386.rpm
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-urlgrabber-2.9.8-2.noarch.rpm
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-2.4.3-4.el4.centos.noarch.rpm

But it could have just been

rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-2.4.3-4.el4.centos.noarch.rpm


CentOS 5 Install Yum

July 10, 2008

CentOS 5

rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/elfutils-libs-0.125-3.el5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/gmp-4.1.4-10.el5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/readline-5.1-1.1.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-2.4.3-21.el5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/libxml2-2.6.26-2.1.2.1.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/libxml2-python-2.6.26-2.1.2.1.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/expat-1.95.8-8.2.1.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-elementtree-1.2.6-5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/sqlite-3.3.6-2.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-sqlite-1.1.7-1.2.1.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/elfutils-0.125-3.el5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/rpm-python-4.4.2-48.el5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/m2crypto-0.16-6.el5.2.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-urlgrabber-3.1.0-2.noarch.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/yum-metadata-parser-1.1.2-2.el5.i386.rpm
rpm -Uvh http://mirror.centos.org/centos-5/5/os/i386/CentOS/yum-3.2.8-9.el5.centos.1.noarch.rpm
yum -y update


Changing Timezone and Updating the Time

November 17, 2007
  1. Log in as root
  2. To check the current time use the ‘date’ command.
  3. Go to the directory /usr/share/zoneinfo. It will give you a list of all available time zones. Choose the most appropriate for your area.
  4. I usually like backups, so backup the previous timezone configuration by copying it to a different location, `mv /etc/localtime /etc/localtime-backup`.
  5. Create a symbolic link from the appropiate timezone to /etc/localtime. Example: `ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime`.
  6. If you have the utility rdate, update the current system time by executing `/usr/bin/rdate -s time.nist.gov`.
  7. Set the ZONE entry in the file /etc/sysconfig/clock file (e.g. “America/Los_Angeles”)
  8. Set the hardware clock by executing: ` /sbin/hwclock –systohc`

Port forwarding HTTP to an internal server

September 22, 2007

/sbin/iptables -t nat -A PREROUTING -p tcp -i ethX \
-d aaa.bbb.ccc.ddd –dport 80 -j DNAT –to eee.fff.ggg.hhh:80

/sbin/iptables -A FORWARD -p tcp -i ethX \
-d eee.fff.ggg.hhh –dport 80 -j ACCEPT

Where:
ethX is your public ethernet number
aaa.bbb.ccc.ddd is your public IP address
eee.fff.ggg.hhh is your interal IP address

Port 80 is the default port for HTTP, unless you changed it to something else on your servers, do the same on the two iptables parameters.