December 2006 - Posts
So after I've solved the clock and time problem on my Linux box, it's now time to think about others. I found Hamachi and wrote a post about it couple weeks ago. I found that it's really simple to install and easy to use when I am not able to have a VPN environment outside the world. Now I got Windows Servers accessing with Terminal Service, and also got Linux boxes accessing using SSH or VNC over XDMCP, it would be more secure if I can access those boxes via those procotols on a VPN based tunnel.
Hamachi is built as a windows client app. it also got linux client. Windows client needs to become paid user to have the "Run as Service" function, and linux will need some more steps to let it run when system boot on. so my next homework is to build my own VPN P2P server communication private network using hamachi and let hamachi running as service on each OS box.
After doing a search to Google, found this post (also listing on Digg) talking about making hamachi windows client running as a service in any windows platform (including XP), and also contained links pointing to let hamachi running as a service on linux, Mac, and other platforms, that's the answer of this homework.
On windows side, running client windows app as a service is an old tricks of using instsrv.exe and srvany.exe, and it's the same way on that post to make hamachi run as a system service inside windows.
On linux side, the main study is to understand the system boot up sequences and know where to put hamachi client also solve the access premission problems.
Read the post about detail explaination and installation steps. I'll just memo the instructions here for my backup note.
Windows Clients / Servers: (original post)
- Download Windows 2003 resource kit tools (or search google for it)
- install the resource kit to get instsrv.exe and srvany.exe on "c:\program files\Windows Resource Kits\" and copy those 2 files to hamachi directory.
- go to hamachi installed dir, run "instsrv.exe AutoHamachi "c:\program files\hamachi\srvany.exe" " to create the system service record. "AutoHamachi" is just service name and can name it yourself.
- open regedit, locate "HKLM\SYSTEM\CurrentControlSet\Services\AutoHamachi\", create a key named "Parameters"
- inside "Parameters" key, new a string value with name "Application" and value "c:\\program files\\hamachi\\hamachi.exe -srvany -config "C:\Documents and Settings\Administrator\Application Data\Hamachi" ", config path is your user account path if you are not running as administrator account.
- go to control panel under services pannel , locate AutoHamachi service, see the properties, on "Log On" tab remember to check "Local System Account" and "Allow service to interact with desktop" , then just start the service and everything is done. (remember to make the startup type to Automatic).
Linux Servers: (original post)
- download the hamachi package.
- making "/usr/src/hamachi" dir., unpack download tar.gz file with "tar -zxvf filename.tar.gz" and put the unzip stuffs in that dir.
- go to "/usr/src/hamachi/package-version/" dir, run "make install" to install hamachi on linux.
- do a "hamachi-init -c /etc/hamachi " to make a public hamachi profile under dir "/etc/hamachi"
- issue and run "tuncfg" to enable root priviledge on tunnelling network for hamachi process
- issue "hamachi -c /etc/hamachi start" to start hamachi client
- issue "hamachi -c /etc/hamachi set-nick server-nick-name" to set server nickname
- issue "hamachi -c /etc/hamachi login" to login to hamachi server
- if no exist network, create self-own one by issuing "hamachi -c /etc/hamachi create network-name"
- if joining existing network, issuing "hamachi -c /etc/hamachi join network-name"
- issue "hamachi -c /etc/hamachi go-online network-name" to make this client online on the network to be seen by peers
- issue "hamachi -c /etc/hamachi list" to list peer machines and IP addresses
- issue "hamachi -c /etc/hamachi go-offline" to get current machine offline from the network
- issue "hamachi -c /etc/hamachi stop" to stop hamachi
- issue "hamachi --help" for all the parameters valid.
- making a hamachi startup script named "/etc/hamachi-start" :
echo "Starting hamachi..."
/usr/bin/hamachi -c /etc/hamachi start
echo "Stopping hamachi..."
/usr/bin/hamachi -c /etc/hamachi stop
case "$1" in
- issue "chmod 711 /etc/hamachi-start" to change script file to runable mode
- under different distribution find out the boot up files and locate "rc.local" file (usually at /etc/rc.d/rc.local) to add the scripts by adding the following code in the last:
if [ -x /usr/bin/hamachi-start ]; then
- OR just create symbolic link of "hamachi-start" into runlevel 3 startup dir "/etc/rc.d/rc3.d/" by issuing "ln -s /etc/hamachi-start /etc/rc.d/rc3.d/S50hamachi-start"
- test if can start and stop hamachi service by using the symbolic link. start by "/etc/rc.d/rc3.d/S50hamachi-start" , stop by "/etc/rc.d/rc3.d/S50hamachi-start stop".
- if everything went well, running hamachi as a startup loading program is done.
but actually there should be the iptables firewall that needs to be set to allow the connection, or else the peers would only see the linux box but may not be able to login. by default the SSH port 22 should be opened thus it should be no problem to connect to the linux hamachi ip with SSH, but if there are other services you want to use, just like what I've setup xdmcp and vnc, it should be convenient to just add those peers hamachi ip-address to iptables to allow full access of the network.
- by default linux hamachi client would also create a network interface called "ham0", when setting up iptable rules, it needs to be target to this interface instead of eth0.
- setup pass-through rule for peer hamachi IPs by editing iptables conf file at "/etc/sysconfig/iptables" and adding like "-A RH-Firewall-1-INPUT -i ham0 -s 22.214.171.124 -j ACCEPT" to allow each peer.
- save "/etc/sysconfig/iptables" file and restart iptables service by issuing "service iptables restart".
- test each connection way to make sure you can really connect via hamachi ip address.
one can have max 16 machines inside a self-created network if using hamachi free service. pretty enough for testing env.
that's it. now I have some Windows Server boxes, some Linux server boxes, and a secure network to connect them over internet.
Technorati Tags: linux , hamachi, fedora, CentOS, VPN, P2P, windows , service
The title came from VMWare KB and just said exactly the problems I've faced those 2 days!
As I've written in the Windows X Server Client post, I used VMWare 5.5 to setup a Fedora Core 6 Linux VM to be the linux test server. the linux kernel version is 2.6.18 and after I finished that post soon I found that my server's system time is little bit strange. it's not sync with the host time.
Since correct time is very important for a server, I think it should be more important in a linux server since there were lots of logs and crontabs that's based by time. The very first thoughts to fix this problem is to use NTP protocol to sync with world time servers. in linux kernel 2.6 there is ntpd for ntp server, in 2.4 it should be xntpd. so I quickly modified "/etc/ntp.conf" file and started the ntpd.
the time is still not sync with real time after I started ntpd. also I found that the ntpd installed is not able to sync to outside server, it will only sync to LOCAL server, even if I turned on udp port 123 in iptables (both in and out), just like what it was written in this maillist I found. also, the system time is slow, it takes more than one second to pass a second (inside this linux guest system). there seems also having problems related to VM hardware's clock settings.
This tooks me one day and didn't find any solution on the internet. finally I decided that maybe it's only happened on linux kernel 2.6.18 and decide to build up another distribution with different kernel version to test again.
I choosed CentOS 4.4 with linux kernel 2.6.9 to build up another linux vm. and after the installation, the system time is still slow like the one inside Fedora vm. this concluded that it will almost happened with 2.6 kernel in VMWare and won't happened in 2.4 kernel (since my colleague had a RedHat 7.2 with kernel 2.4.18 running without the time slow problem). some posts I read indicated that this should have something related to system clock. so I started dig into that direction.
A search to Google finally found the answer. From VMWare KB. It's exactly the answer of this problem if you are running kernel 2.6 inside VMWare. the reason that caused the slowing time inside guest system is because of that the guest clock frequency is setting too high than the host OS can offer. in 2.4 kernel the clock rate is set to 100HZ and after 2.6 kernel the clock is set to 1000HZ on compiling time, thus cause the timer in guest OS slower than host OS. refer to this KB for more detail explaination.
Just follow what the KB said to tune bootup kernel options for both slow time and quick time problem, like the following (GRUB case):
append="resume=/dev/hda6 splash=silent clock=pit nosmp noapic nolapic"
"clock=pit" is to fix quick clock problem, "nosmp noapic nolapic" is to fix slow clock problem.
after a reboot of guest linux (both my Fedora one and CentOS one) , the clock is back to normal and strangely that the ntpd also back to normal work and can query outside time server without problems. cool!
As also provided in another VMWare KB talking about Timekeeping in VMWare Virtual Machine, it is also able to use VMWare Tools to sync guest OS time with host one. by installing VMWare Tools in Linux server, there will be a vmware-guestd running and by setting parameter "tools.syncTime = TRUE" inside VMWare .vmx setting file, time will be sync.ed with host OS using VMWare Tools and will be not necessary to run ntpd or ntpdate in crontab to sync your time inside guest system, it will auto sync with host OS and it will now be only the host OS that needs to sync with world time server thus save the bandwith also the loading of outside time servers.
finally solved the time problem, and got to learn one more linux distribution install, also get deeper understanding of ntpd during this problem solving, nice (tough) learning.
actually Fedora Core distribution is pretty different from CentOS installation, CentOS is pretty much like RedHat distribution and many daemon names are different from Fedora and CentOS (RedHat). another tough learning to remember those difference! (should be more differences if touching FreeBSD systems!)
anyway, now I can also setup my xdmcp and vnc server env on my CentOS guest system and now have 2 guest linux systems to start my learning of those network services installation. keep walking...
Technorati Tags: linux , redhat, fedora, CentOS, ntp, clock, kernel , vmware
Well, still been busy on procesing my working visa things so recently didn't update this blog often. everything is going well and now all I have to do is wait for the process result. during this month my current company just move to a new big office and also the company's System and Networking engineer resigned his work before the office move. so we as developers also have to plan the new office's network topology, buying necessary network equipments, setting up NTT VDSL and office network routing to make the new office network working like usual. We as developers also need to touch the system maintainance things to manage those linux servers, some real ip for staging server is changed and have to change firewall so that it can work like usual, things like that. it's a big headache for me counting as a Windows pro but rarely know things on linux system, but I still managed to overcome all this and make it to here. that's the reason I didn't write things in this month, tooooooo busy!!
just spend the whole weekend studying most of fundamental things of a linux system. I managed to setup a Fedora Core 6 system on VMWare 5.5 inside my LAN to have an experiment env. for testing those linux commands during my reading. The goal is to understand and know how to setup those network services like DNS / Firewall / Software Router / Mail Server / WWW server / Database Systems on a linux env. just like what I can easily do those on a Windows server system. but after I've get used to use SSH clients to operate the server on shell mode, and before I started to study those network services, I am still likely to have a Window system on my linux server so that I can have not only terminals but also those GUI dev. env.s like Eclipse. so I started digging those info about setting up windows X server (client) to connect remote linux server using X protocol and VNC. the goal is to do this remote connecting things just like I can easily terminal service to a Windows server. and here we go.
My primary info is mostly from http://linux.vbird.org , which is written in Chinese, actually the author also got those contents published in books selling at Taiwan area, get one of them if you feel needed. Thanks to VBird for organizing those info systematically...
First of all, some nice ssh clients people used in Japan area:
some nice ftp and scp clients people use in Japan area:
some famous Windows X Server:
I am using the latest version of Fedora Core 6 (2.6.18-1.2849.fc6) to set up my linux server on VMWare 5.5.3 build 34685. notice that when setup the VM the FC6 DVD iso installer seems not knowing VMWare's SCSI disk and will not find any patition during installation, thus I had changed the disk type to IDE to let the installation process finished without toubles.
After installation, first SSH to the server, su to root, and then setting up the firewall rules. I'll allow the LAN area to access my linux server only. if using the default setup during the installation, iptables and TCP_Wrappers (hosts.allow / hosts.deny) were enabled by default. (I've disable SELinux first during the installation to prevent more permission trouble now). so first to touch the iptables things:
- Edit "/etc/sysconfig/iptables" (in below follow the order to input line by line, firewall rules got orders)
- add "-A RH-Firewall-1-INPUT -p udp --dport 177 -s 192.168.1.0/24 -j ACCEPT" to allow LAN to pass xdmcp udp 177 port
- add "-A RH-Firewall-1-INPUT -p udp --dport 177 -j REJECT" to block other subnet to using xdmcp.
- add a row allow access to LAN IPs like "-A RH-Firewall-1-INPUT -i eth0 -s 192.168.1.0/24 -j ACCEPT"
- "eth0" is the main network interface, "192.168.1.0/24" is the LAN subnet, "RH-Firewall-1-INPUT" is the default chain name set when installing the server
- save the file and restart iptables by issuing "/etc/init.d/iptables restart"
after iptables were set, the next is to also set TCP_Wrappers:
- Edit "/etc/hosts.allow"
- add access grant to local LAN, like "ALL: 192.168.1.0/255.255.255.0 : ALLOW"
- edit "/etc/hosts.deny"
- add no access to others not set like "ALL : ALL : DENY"
- in old linux like RedHat 7.x, it's needed to restart xinetd service to let new settings take effect.
- in new linux like Fedora Core 6, change will take effect immidiately once saved those files.
after setting the firewall, it's time to start configuring xdmcp.
I am using KDE as my Window Manager, so I have to enable kdm to accept xmdcp at udp port 177:
- edit kdmrc at "/etc/X11/xdm/kdmrc"
- on [Xdmcp] block enabling the following:
- Port=177 (uncomment it)
- predefined in the file for Xaccess is "Xaccess=/usr/share/config/kdm/Xaccess" , change to "Xaccess=/etc/X11/xdm/Xaccess" for easy management
- on [X-:*-Core] block do the following to enable X listening to tcp port:
- comment "ServerArgsLocal=-nolisten tcp"
- umcomment "ServerArgsRemote="
- save the file and exit.
before start kdm , do a "killall kdm" to make sure no kdm is running . using "netstat -tunlp" to check the process and ports been listening. after running "kdm" on shell, check the port listenning again. there should be a kdm process listening udp 177 port, also couple X processes listening tcp port 6000. if you see things like this, the server side settings are done.
using X-Win32 or Exceed on your windows client, you can either using broadcast mode to let the client find the xdmcp listener for you or using query mode to specify the ip address of the linux server to connect. after connect it will look like this:
that's all about using windows and xdmcp to connect a linux server using X window interface.
As using xdmcp, the client and server are using X protocol to communicate, and may using a lot of bandwidth thus it should be pretty ok if using on a local LAN but should be not suitable on a internet environment, especially if only have a low bandwidth ADSL network.
VNC had always been our good friend long time ago. it use lower bandwidth and thus makes it suitable via internet, just like what we are always using Windows RDP terminal service in windows world.
It is also possible to using VNC as network protocol, instead communicate using X, to display X env. in a windows or other client like Mac, since VNC viewer now can be installed on many platforms (and it's free!) thus make this way more convenient for our work.
let's setup a VNC server on linux and still using xdmcp to let VNC client be able to connect to KDE just like using a X server on windows client. the way this is working is because of that now VNC server is acting as network server to send the desktop to VNC client and it's reside in linux server and communicate with xdmcp and X inside the machine "locally"!!
first of all, configuring vncserver on linux (make sure you install it or just RPM and install):
- edit "/etc/sysconfig/vncservers"
- comment everything and add the following:
- add : VNCSERVERS="1:user"
- add : VNCSERVERARGS="-geometry 1152x864 -query localhost" # 1152x864 is screen resolution, "-query localhost" is to instruct vnc server to query local X and thus will connect to kdm and KDE.
- the setting above is to open only one vnc server for once user listen to port 5900+1 = 5901. for setting up more then 1 vnc server, using the following settings:
- add : VNCSERVERS="1:user1 2:user2 3:user3"
- add : VNCSERVERARGS="-geometry 1152x864 -query localhost"
- add : VNCSERVERARGS="-geometry 1152x864 -query localhost"
- add : VNCSERVERARGS="-geometry 1152x864 -query localhost"
- save the file and exit editor
- before start vncserver, make sure you start kdm already (netstat -tunpl to check process running and ports been listening).
- start vncserver by issuing "/etc/init.d/vncserver start"
- the users specified above, will then all have a .vnc directory in their home dir.
- su to each above users
- edit the ~/.vnc/xstartup file and comment out everything (by default it's using twm as window manager so just comment out them).
- save the file and exit the editor
- issue "vncpasswd" to set the vnc viewer password for current user
- exit this user and su to the other user
- after edit all the xstartup file and setup vncpasswd for users specified in vncservers file, restart vncserver and kdm by issuing the following commands:
- issue "/etc/init.d/vncserver stop "
- issue "killall kdm"
- the above is to clear vncserver and kdm, now start them again
- issue "kdm"
- issue "/etc/init.d/vncserver start"
- depending on how many users you set on vncservers file, corresponding vncserver will be setup on port 5900+1 , +2 , +3 waiting for connection.
- server setting is finished.
now at windows or other client like Mac or other linux GUI env.s, using VNC viewer to connect to the linux server using the ports specified above (5901 ,5902, 5903), you should also see the KDE login window in those 3 VNC sessions just like what you do using X-Win32 and xdmcp. (make sure you've opened 590x ports on your iptables settings, I've already opened my LAN for free access to server so it's no problems on connections here.) pic like this:
that's it, now I can have X window on my windows client to work on those linux tasks, not bad...
Technorati Tags: linux , redhat, fedora, xwindow, vnc, xdmcp, x-win32 , exceed