Archive for the ‘servers’ Category

SVN over HTTP

January 31, 2011

Hello there true believers, been a while since I’ve written something here.


A quick FYI on those wanting to use SVN but are restricted to use it from within a network with a proxy.
If you try using SVN over HTTP, it most likely won’t work by default since SVN uses a different network port (usually 3690 for *nixes) and HTTP proxies by default use 80 or 8080 as their ports.
If you try checking out or updating or committing to/from an SVN repo by default, you’ll run into a problem saying SVN couldn’t connect. Uh oh spaghetti-oh. 🙂
In my Ubuntu 10.04 machine, what I do is open (with sudo/root properties) the file:

/etc/subversion/servers

and uncomment (or add, if the following are not present) these parameters:

http-proxy-host = yourproxy.com
http-proxy-port = port

e.g.

http-proxy-host = 10.10.10.10
http-proxy-port = 8080

I save the file, then try SVN again. Voila. I’m back to coding again. 🙂

Reference/s:

IPCop Linux, route command, and network routing

September 16, 2009

This short post is about the dilemma a coworker of mine just had this morning regarding network packets, and a not fully functional IPCop Linux installation.

The Dilemma

The server runs IPCop, which allows a PC to run as a firewall appliance. The IPCop server has 2 NICs, eth0 and eth1. Eth0 is connected to a Class A private LAN while eth1 uses a Class C address to connect to the public Internet. The problem however is that the Internet is accessible (Google, Yahoo! etc.) but not private LAN machines and addresses.  The private LAN’s gateway return ping replies, but not the DNS server.

Detective Work (i.e. Troubleshooting)

What I did was to check all possible causes for this problem: restart the network, checked logs for error messages and others, though some of these had already been done, but I just want to be doubly sure myself. I next checked the firewall using the iptables command. There were tens of lines of firewall rules, along with numerous chains. Since I was in a hurry at that time, I decided to skip the detailed checking of the firewall rules for the moment, even hough I have experience dealing directly with iptables, and not with the higher level application firewalls that just modify it. Next I tried to ping again the DNS server. Adding a -v in the ping command to make it more verbose, I noticed that packets were being successfully sent to the DNS server, but no packets were coming back. I thought to myself that the iptables firewall is one good suspect for this, but I’ll try a few more checks before I go to the nitty gritty of iptables firewall rules. I did ifconfig ethX up and then  down but to no avail. Replace the X with the NIC number you wish to up/down.

The Fix

I next checkd the routing table using the very useful route command. The static IP route looked fine, but I noticed that it was rathe incomplete, given that it has 2 NICs. What I mean by incomplete is that the route from the public, Class C network has routes for going in and out of the destination network and host, but the private LAN doesn’t have a route for traffic going into the IPCop server. It only has a route for traffic coming from the Class A private LAN NIC. Bingo was its name-o. 🙂 Apparently the reason why ping packets weren’t making their way back to the IPCop server was that they weren’t being routed correctly back to the IPCop server itself. This was further supported by using the traceroute command. I traceroute-ed the private LAN DNS server and as expected, the routing of the packet was all messed up. The traceroute packets for the private LAN DNS server were exiting through eth1, and out to the public Internet already. No wonder it doesn’t have a private LAN connection! 🙂

So the fix was to add a correct route to the routing table using the route command. The new route should, well, route the packets correctly from the  private LAN back to the IPCop server, and to make sure that the class A private LAN traffic enters/exits via the eth0 NIC. To do this the command

route add -net NETWORK netmask NETMASK gw GATEWAY

was used. Just replace NETWORK, NETMASK, and GATEWAY with the appropriate values for your network. In our case, NETWORK was the destination host ( the local machine, given by 0.0.0.0) and GATEWAY was the gateway of the Class A network of the private LAN.

Sure enough, after adding that static route, the Class A private LAN became accessible. 🙂

route add -net 192.57.66.0 netmask 255.255.255.0 gw ipx4route add -net 192.57.66.0 netmask 255.255.255.0 gw ipx4

Fixing the PHP error/warning “Cannot modify header information – headers already sent “

August 18, 2009

This will be a quick post/note-to-self since I’m pretty occupied. Actually, the title of this post should have been “How to bloody fix the deceptively easy but hard to find confounding error in PHP headers: “warning Cannot modify header information – headers already sent”. But that’s too bloody long (though it would be interesting to find out in the future how WordPress concatenates long URLs…). The reason why I call it deceptive will be clarified at the 3rd entry below 🙂

The 2 primary parts of an HTTP request response are the headers and the body, which should be sent separately. Now in PHP sometimes some programmers, not just novice ones but long time ones (ehem…like me…) forget that we’re modifying them programmatically, which can sometimes cause errors. The header must always be sent first before the body, wherein both are coming from the web server. This is highlighted in this Wikipedia HTTP request example. For example, the php function header() can modify some of the (obviously) header parameters, most/all of which are listed in this Wikipedia list of HTTP headers. The above PHP error occurs because the body (or part of it) has already been sent by the server to the client, afterwhich a change of header values follows, either from the client or server.

Now, to finally fix the deceptively easy to fix but hard to find source of the error

Warning: Cannot modify header information – headers already sent by (<some of your PHP source files should be listed here>)

You can check the following:

1) If you’re using the header() function or some PHP function that modifies the header or controls the flow of action of your pages (e.g. from one page to another), you should inspect those. Usually it’s better to use conditional statements (e.g. IF or ELSE) to isolate the execution of one part of your code from another. It is quite likely that the error comes before or at the line of this function.

2) Make sure you don’t output/print/echo anything to the client (body) before sending/changing the headers. Again, conditional statements are useful here.

3) Finally, and the easiest to overlook, is to remove any white space outside the PHP start and end tags (<?php ?>). This is quite often the easiest thing to miss (for me at the least). The reason for this deceptive white space causing an error in PHP is that the white space is still interpreted as an echo statement printing a blank line, which interrupts the format of the HTTP header (see Wikipedia header format example above).

Of course the disclaimer here is that you are to most likely encounter this error if you’re more or less building your PHP application from the ground up, or without using web frameworks. It’s more unlikely and unusual to receive this error while you’re using an MVC based PHP framework.

warning Cannot modify header information – headers already sent But

In Linux, no cpu-z you see…

June 22, 2009

… which may be bad at the start, but isn’t so if you really know how powerful Linux is. In this case, you don’t really need to acquire a cpu-z-like software, unless of course you’re freaked out by the command line (which we’ll use in this case).  Linux (at least those that use kernel versions 2.6 and above) have quite  an array of commands that lets you acquire most info that cpu-z will give you on a Window$ box, sometimes less, sometimes more. These commands are especially useful in cases like (this was my case a week ago, that’s why I had to find out about them) there’s no graphical interface for you since you’re either remotely doing administration or the server just doesn’t have any graphical server/service installed.

To list information about the CPU enter the command

cat /proc/cpuinfo

To list your PCI devices type the command

lspci

To acquire information about your installed memory/RAM sticks or modules, one command to do this is

sudo dmidecode —type 17

To check your hard drives, the following commands give you loads of info

cat /proc/diskstats | egrep "^\s?+8"
df -hT
ls -lh /dev/disk/by-path/
ls -lh /dev/disk/by-id/
ls -lh /dev/disk/by-uuid/
cat /proc/scsi/scsi

you then can find out disk info by running the following on each node listed (device name in third column):

sudo fdisk -l /dev/NODE (e.g. sudo fdisk -l /dev/sda, if you have SCSI drives)

There are quite a lot more commands to get information about the hardware you are running, without shutting it/them down so you can open them up and check the hardware yourself. Or you won’t have to grab your hardware’s manual (whether locally or online) just to get info about your hardware. Good especially for sys ads like me. 🙂