SSH Login Takes a Long Time

Has it ever happened to you that logging in to an SSH server takes a long time? More than, say 20, 30 seconds? Well, there are many solutions out there to fix it, some may even make your system less secure. So let’s go to the source of SSH, so to speak, for a resolution. If you head over to ssh(1) takes a long time to connect or log in, you will see that it’s an issue with DNS resolution. To resolve this issue, try the following steps:

You need to change the sshd config file …

sudo vim /etc/ssh/sshd_config

… and make sure you have this line uncommented

UseDNS no

Save the file and restart SSH daemon (service) like so

sudo service sshd restart (Fedora, Red Hat, CentOS)

or

sudo /etc/init.d/sshd restart (Debian, Ubuntu)

Hat tip: Slow SSH login;

Remote Login with GDM and VNC on Fedora 11

Do you want the ability to VNC into your remote Linux computer and login to the GUI as if you were right next to the machine? Then you need to setup VNC with GDM. These steps were tested on Fedora 11.

Install VNC

You need to install VNC first. If it’s already installed, running the following command may either do nothing or upgrade it.

sudo yum install vnc-server

Turn Off VNC Service

sudo chkconfig vncserver off

sudo service vncserver stop

Install xinetd

You need to have xinetd installed. If it’s already installed, running the following command may either do nothing or upgrade it.

sudo yum install xinetd

Enable XDMCP

sudo vim /etc/gdm/custom.conf

Your file should have following lines (there may be other lines so leave them be)

[xdmcp]
Enable=true

[security]
DisallowTCP=false

Create VNC Service

sudo vim /etc/services

Edit the file so that the lines with vnc-server look like

#vnc-server 5900/tcp # VNC Server
#vnc-server 5900/udp # VNC Server

And add the following line

vnc1024 5900/tcp # VNC and GDM

Create xinetd Service

Create a file as below

sudo vim /etc/xinetd.d/vnc1024

And make sure the file has the following contents

service vnc1024
{
disable = no
socket_type = stream
protocol = tcp
group = tty
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -geometry 1024×768 -depth 16 -once -fp /usr/share/X11/fonts/misc -securitytypes=none
}

Restart xinetd

You should restart the xinetd service.

sudo service xinetd restart

VNC into the Server

Using a VNC client on another computer, try to VNC into the server. If it doesn’t work, you may have to restart the server.

sudo reboot

Hat Tips: Run VNC and GDM for headless boxes; VNC & GDM; Using remote X applications under Fedora Core 3 (re: xhost usage);

Yum repomd.xml Error

I installed Fedora 11 in a VMware virtual machine from a DVD iso image. After installation, I went on to do yum update and got this message: Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Searching the web revealed one most-recommended solution: check your DNS settings. It turns out, repomd.xml is a file located on the mirror from which you are trying to download updates, new package, whatever. The error message is displayed when yum is unable to either find or get the repomd file.

The first thing you should check is your Internet connection. Maybe try to ping some server (ping -c 3 google.com). If your connection is fine, the issue could be with DNS settings, proxy issues, or maybe the mirror you are connecting to is having problems. One solution I found said they simply waited some hours and it worked. It indicates to me that maybe the mirrors were having a hard time when they first tried but when their load decreased things were ok.

When I checked, eth0 on my Fedora install was disabled. I had to enable it, make sure network card was connected on VMware, brought down the interface and brought it back up. It used DHCP to get a new IP. I tested a ping to a server and it was successful. Now yum worked just fine.

Enable eth0

To enable eth0, I had to change the ifcfg-eth0 file. I ran the following commands:

sudo vim /etc/sysconfig/network-scripts/ifcfg-eth0

And made sure the following two lines were present:

ONBOOT=yes

BOOTPROTO=dhcp

Bring Down Interface and Bring it Up

To bring down my eth0 interface, I ran

sudo ifdown eth0

To bring it back up, I ran

sudo ifup eth0

How to Enable SSH in ESXi – VMware

By default you cannot SSH in VMware ESXi. Follow the steps below to enable SSH on ESXi

1. On ESXi server’s administration window where you see <F2> Configure and <F12> Shutdown/Restart options, prese ALT+F1 to enter into CLI mode

2. type  unsupported then enter.

3. on password type unsupported (if you haven’t set any password otherwise use the one which you have set) hit enter

4. Now on CLI prompt go to directory /etc

# cd /etc

5. Open config file called inetd.conf and go to the line where it show #SSH, remove # then save this file and exit

# vi inetd.conf

6. Run following command

# ps -a | grep inetd

7. which shows process id 1234 (this process id would be different for each server)

8. Kill that process

# kill 1234

9. Run inetd command

#inetd

Open SSH and login to your ESXi server.

Cheers

Sh

Reference

Enable SSH for ESXi

Choosing Server Names

A very interesting discussion over at reddit (What is a good name for a server?) got me thinking on how to choose server names. In the same discussion someone posted a link to RFC 1178, which contains guidelines on choosing names for computers. I thought why not try to come up with some alternate ideas?

I am of the opinion that one should pick a theme and choose names from within it. For example, a very popular theme is mythical creatures or deities. If you choose Greek gods and heroes, then all your servers are named using their names. Extending this idea, why not pick different themes for different types of servers and devices? For example, Greek deities for servers, colors for printers, classical musicians for network devices, etc. This allows one to identify not only the device in question but also its general classification.

Sometimes it’s just easier to name servers after their function when users are neither very creative nor want to be. For example, if a bunch of servers are for databases only, they could be called DB1, DB2, and so on. Not much fun, obviously, but some situations might warrant this approach. Therefore, we need to keep an open mind.

I mostly prefer lowercase names because they are easier to type. They are not passwords where case sensitivity might be expected or desired. And since almost all commands on Linux/Unix are lowercase, it just flows with it if that’s your platform of choice.

Some people might be consultants and may have to choose names for devices in multiple organizations. In such cases you might want to choose themes for one organization and not repeat them for others. It might be a bit more difficult to know which Hnoss if two or more organizations have the same name for their devices.

This discussion is not limited to device names only. Logins and passwords could also be created using themes and their set of names.

Some suggestions for themes: types of sports (soccer, football, baseball, cricket …); sportspeople (tiger, graff, sampras, jonty, warne, nadal …); rivers (nile, indus, ganges, danube …); poets (keats, angelou, iqbal, bronte …).

Django in Debian Lenny

Installing Django in Debian is very similar to in Ubuntu. Here we will use Postgresql so there will be a slight difference from when using MySQL.

sudo aptitude install postgresql python-psycopg2 python-django