This is an old revision of the document!
Note: you should perform these operations while logged in with root privileges. You may become root with the commands su - or sudo su -.
shows you how your ethernet interfaces are configured. Most often eth0 will be the primary device.
root@yourserver:/# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0B:99:99:00:00 inet addr:192.168.3.115 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::290:4bff:9999:0000 /64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1633075 errors:0 dropped:0 overruns:0 frame:0 TX packets:2512154 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:690787053 (658.7 MiB) TX bytes:221517909 (211.2 MiB) Interrupt:5 Memory:faff6000-faff8000
shows the paths to other networks, most notably the default gateway (which for IPv4 is 0.0.0.0).
root@yourserver/# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.3.1 0.0.0.0 UG 0 0 0 eth0
shows you which ports are open, and which processes listen on them (if you are root). It also shows the address of the other end of each open connection.
root@yourserver:/# netstat -lnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:2020 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:504 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 16825/citserver tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 27329/webcit tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 16825/citserver Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 1569009 16825/citserver /var/run/citadel/citadel.socket unix 2 [ ACC ] STREAM LISTENING 1569016 16825/citserver /var/run/citadel/lmtp.socket unix 2 [ ACC ] STREAM LISTENING 1569019 16825/citserver /var/run/citadel/lmtp-unfiltered.socket
If you prefer to see the names of the services than their port numbers you can omit the -n
If you have chosen to let your citserver bind a secific IP, the whole thing will look a little different. Lets say, your machine has the ips 127.0.0.1(loopback) 184.108.40.206 and 220.127.116.11, and you want citadel just to answer queries on 18.104.22.168 since other services are already answering on the above listed ports on 22.214.171.124 the lines will look like that:
tcp 0 0 126.96.36.199:504 0.0.0.0:* LISTEN 16825/citserver
so this not just removes the bind to 188.8.131.52, but also implicitely
tcp 0 0 127.0.0.1:505 0.0.0.0:* LISTEN 16825/citserver
won't be accessible; If you run Webcit with an IP connection (and not the unix domain socket “citadel.socket”), you need to point it to 184.108.40.206 port 504; 127.0.0.1 port 504 won't be accessible, and you will be pointed to the What's wrong when I get the message: Connection refused: can't connect to 127.0.0.1.citadel?.
Telnet is an unencrypted remote terminal tool. But we can also abuse it to check whether citadel is able to do its job:
- by talking to localhost (127.0.0.1) from a shell on the host your citserver runs on to check its actually citadel you're talking to
- if you replace 127.0.0.1 by i.e. smtp1.google.com check whether your Citadel server is able to send mail out; the replies will look a little different then.
- also you can use it to check whether the outside world is able to reach you. Use some outside Internet connection such as a mobile or an internet cafe to your Citadel server, or ask someone outside of your network to do this for you.
We have illustrated the conversation with - > and < - to show what you type, and what the mail server (in this case a Citadel) sends back.
root@yourserver:/# telnet 127.0.0.1 25 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. ->220 yourserver ESMTP Citadel server ready. <-ehlo localhost ->250 Hello localhost (localhost [127.0.0.1]) ->250-HELP ->250-SIZE 10485760 ->250-PIPELINING ->250-STARTTLS ->250-AUTH=LOGIN PLAIN <-MAIL FROM: firstname.lastname@example.org ->250 2.0.0 Sender ok <-quit ->221 Goodbye... Connection closed by foreign host.
You could make Citadel receive or send out an email this way. Furthermore, you have now confirmed that you are talking with the Citadel SMTP service, not with another email program left over from a previous or default installation.
The reply to the EHLO command also shows you which kind of authentication the host supports (another sample would be CRAMD-MD5). Citadel itself just supports “plain” auth, in receiving and sending direction. This is almost plaintext, so you should wrap a TLS session around it.
If you don't see
220 yourserver ESMTP Citadel server ready.
but something like Postfix, Exim, QMail you are not talking to your Citadel server.
Note: depending on your system netcat may either be named nc or netcat; we'll name it nc in the examples.
Netcat was designed for the purpose for which we misused telnet earlier. If you want for example to post a message using an automated script, telnet would add special control characters, which will spoil your effort. You need to use netcat in this case. But netcat can do even more: It can open server sockets (like citserver does) or speak UDP.
The problem we want to use netcat for in this example is the following: You want to know which headers your browser sends to webcit. For that we need netcat to open a server socket, our browser will talk to:
nc -l -p 8888
Now point your browser to http://192.168.3.115:8888 (or the ip the box has your netcat is running) and see what netcat says:
GET / HTTP/1.1 Host: 127.0.0.1:8888 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20061205 Iceweasel/18.104.22.168 (Debian-22.214.171.124+dfsg-2) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en-us;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-IR-111,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive
now you can press control c to terminate your netcat, or type into it and say some nice things to your browser.
Here we want to use netcat to talk to your citserver in citadels native tongue; this is usualy done through TCP Port 504 (see your output of netcat above); (we'll add » and « for whats Citserver telling you, and what we tell him; You'll get similar output if you configure and compile webcit with CFLAGS += -D SERV_TRACE)
# nc 127.0.0.1 504 >> 200 poza Citadel server ready. << ECHO test >> 200 test << QUIT >> 200 Goodbye.
Now if you want to do this from within a shellscript, you'll get the problem that NetCat will close the connection to the server when its input channel is closed; ence we need to make it waiting; we'll use '()' (which invokes a sub-shell) for that:
( printf "ECHO test\nQUIT\n" sleep 10 ) | nc 127.0.0.1 504
To resolve IP addresses from names like google.com, your computer needs nameservers; the file /etc/hosts shows your programs where to find it. Verify that thie file exists, and that the IP address inside is reachable with ping.
Next you can use the nslookup or host utility to check if it's working:
->host google.com <-google.com has address 126.96.36.199
(and some more…) Or to find out who is the mail exchanger there:
host -t mx google.com google.com mail is handled by 10 smtp2.google.com. google.com mail is handled by 10 smtp1.google.com. google.com mail is handled by 10 smtp3.google.com. google.com mail is handled by 10 smtp4.google.com.