Wednesday, November 18, 2009

Upgrade Fedora 11 to Fedora 12

I was eager to upgrade my Fedora 11 to Fedora 12. I expect the F12 will make evolution work with MS exchange 2007. Since working place switched mail server  to Exchange 2007. The evolution on Fedora 11 became useless. There were reports on sucessful connections from evolution 2.28 to M$ exchange 2007.

My laptop has not CD-ROM. The options for me were Boot from Fedora 12 live USB, installation from harddisk or preupgrade. Since Fedora 11, the preupgrade function has been enabled. I tried this with
sudo /usr/bin/preupgrade-cli. It started with downloading images and related rpms. After this completed and starting reboot and get to upgrade-installation. This step was smooth.

Unfortunately the first boot after update was frozen. Xorg was not started. I booted it up with a live Ubuntu USB and changed the start level to 3. After reboot it, I can login at the console or at a networked PC. This signalises the installation was basically ok. Only need to fix X window. I did not got any fix after sent out a few email to fedora-list.

Check anaconda.xlog Xorg.0.log, one warning message was a bit informative, google this message and leading to this page
it suggested to add nomodeset to kernel argument. In fact, It worked after removed nomodeset.

After started to level 5, login to gnome desktop. Looks nice. Tried firefox, jpilot, etc. Most of applications work, a few not-working:

evolution to exchaneg crashed.
OO writer can't read Chinese doc

Overall, this is a nice upgrade since I started with redhat, FC1 to Fedora 11.

Nice day

Sunday, November 15, 2009

ssh ABC

Access Remote GUI Programs Using SSH Forwarding
ssh -C -X user@host.domain gnome-terminal

> vi /etc/ssh/sshd_config

and set:
X11Forwarding yes

> vi /etc/ssh/ssh_config

and set:
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

> /etc/init.d/ssh restart

You done and can connect with forwarding

Auto login via ssh
  1. Create a public ssh key, if you haven’t one already.
    ssh-keygen will create key as .ssh/id_rsa
  2. Make sure your .ssh dir is 700:
    chmod 700 ~/.ssh
  3. Get your public ssh key on the server you want to login automatically.
    A simple scp ~/.ssh/ is ok.
  4. Append the contents of your public key to the ~/.ssh/authorized_keys and remove it.
    Important: This must be done on the server you just copied your public key to. Otherwise you wouldn’t have had to copy it on your server.
    Simply issue something like cat >> .ssh/authorized_keys while at your home directory.
  5. Instead of steps 3 and 4, you can issue something like this:
    cat ~/.ssh/ | ssh -l remoteuser 'cat >> ~/.ssh/authorized_keys'
  6. Remove your public key from the home directory on the server.
Change ssh port or get more port
sudo vi /etc/ssh/sshd_config

change or add

Port 22
Port 446

Reverse SSH or Tunnel ssh

SSH is one of the most versatile tools for Linux, but most people only ever use it one way - to use the server to send data to the client. What you might not know is that it's also possible to switch the usual logic SSH and use the client to send data to the server. It seems counterintuitive, but this approach can save you having to reconfigure routers and firewalls, and is also handy for accessing your business network from home without VPN.
You'll need the OpenSSH server installed on your work machine, and from there you need to type the following to tunnel the SSH server port to your home machine:
ssh -R 1234:localhost:22 home_machine
You'll need to replace home_machine with the IP address of your home machine. We've used port number 1234 on the home machine for the forwarded SSH session, and this port needs to be both free to use and not blocked by a local firewall. Once you've made the connection from work, you can then type the following at home to access your work machine:
ssh workusername@localhost -p 1234
This will open a session on your work machine, and you will be able to work as if you were at the office. It's not difficult to modify the same procedure to access file servers or even a remote desktop using VNC. The only problem you might find is that the first SSH session may time out. To solve this, open /etc/ssh/sshd.conf on your work machine and make sure it contains 'KeepAlive yes' and 'ServerAliveInterval 60' so that the connection doesn't automatically drop.

this part was adopted from

IT and Ecology

This is a starter for this blog. A few words on IT and ecology resonates in my mind. Sound IT item should be a friendly one, to user, to environment, socially and economically. Simple and pratice solutions, tips may fit this frame. Multiple functionalities of modem devices may be a bad things, or waste, many of them are not used. I hope my blogger will follow this logics.