لطفا منتظر باشید ...
/etc/inetd.conf
A sample inetd.conf file is shown here. It contains entries for the most commonly used Internet services:
ftp stream tcp nowait root /usr/sbin/in.ftpd
in.ftpd -l
telnet stream tcp nowait root /usr/sbin/in.telnetd
in.telnetd
name dgram udp wait root /usr/sbin/in.tnamed
in.tnamed
shell stream tcp nowait root /usr/sbin/in.rshd
in.rshd
login stream tcp nowait root /usr/sbin/in.rlogind
in.rlogind
exec stream tcp nowait root /usr/sbin/in.rexecd
in.rexecd
comsat dgram udp wait root /usr/sbin/in.comsat
in.comsat
talk dgram udp wait root /usr/sbin/in.talkd
in.talkd
uucp stream tcp nowait root /usr/sbin/in.uucpd
in.uucpd
tftp dgram udp wait root /usr/sbin/in.tftpd
in.tftpd -s /tftpboot
finger stream tcp nowait nobody /usr/sbin/in.fingerd
in.fingerd
systat stream tcp nowait root /usr/bin/ps
ps -ef
netstat stream tcp nowait root /usr/bin/netstat
netstat -f inet
time stream tcp nowait root internal
time dgram udp wait root internal
echo stream tcp nowait root internal
echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
chargen stream tcp nowait root internal
chargen dgram udp wait root internal
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind
rquotad/1 tli rpc/datagram_v wait root
/usr/lib/nfs/rquotad rquotad
rusersd/2-3 tli rpc/datagram_v,circuit_v wait root
/usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd
sprayd/1 tli rpc/datagram_v wait root
/usr/lib/netsvc/spray/rpc.sprayd rpc.sprayd
walld/1 tli rpc/datagram_v wait root
/usr/lib/netsvc/rwall/rpc.rwalld rpc.rwalld
rstatd/2-4 tli rpc/datagram_v wait root
/usr/lib/netsvc/rstat/rpc.rstatd rpc.rstatd
rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd
rpc.rexd
100083/1 tli rpc/tcp wait root
/usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd
ufsd/1 tli rpc/* wait root /usr/lib/fs/ufs/ufsd
ufsd -p
100221/1 tli rpc/tcp wait root
/usr/openwin/bin/kcms_server kcms_server
fs stream tcp wait nobody /usr/openwin/lib/fs.auto
fs
100235/1 tli rpc/tcp wait root /usr/lib/fs/cachefs/cachefsd
cachefsd
kerbd/4 tli rpc/ticlts wait root
/usr/sbin/kerbd kerbd
printer stream tcp nowait root
/usr/lib/print/in.lpd in.lpd
100234/1 tli rpc/ticotsord wait root
/usr/lib/gss/gssd gssd
dtspc stream tcp nowait root /usr/dt/bin/dtspcd
/usr/dt/bin/dtspcd
100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd
rpc.cmsd
/etc/services
Many inetd services must be mapped to a specific port number. A sample /etc/services file, shown below, defines port numbers for most of the commonly used services:
tcpmux 1/tcp
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
time 37/udp timserver
name 42/udp nameserver
whois 43/tcp nickname
domain 53/udp
domain 53/tcp
bootps 67/udp
bootpc 68/udp
hostnames 101/tcp hostname
pop2 109/tcp pop-2
pop3 110/tcp
sunrpc 111/udp rpcbind
sunrpc 111/tcp rpcbind
imap 143/tcp imap2
ldap 389/tcp
ldap 389/udp
ldaps 636/tcp
ldaps 636/udp
tftp 69/udp
rje 77/tcp
finger 79/tcp
link 87/tcp ttylink
supdup 95/tcp
iso-tsap 102/tcp
x400 103/tcp
x400-snd 104/tcp
csnet-ns 105/tcp
pop-2 109/tcp
uucp-path 117/tcp
nntp 119/tcp usenet
ntp 123/tcp
ntp 123/udp
NeWS 144/tcp news
cvc_hostd 442/tcp
exec 512/tcp
login 513/tcp
shell 514/tcp cmd
printer 515/tcp spooler
courier 530/tcp rpc
uucp 540/tcp uucpd
biff 512/udp comsat
who 513/udp whod
syslog 514/udp
talk 517/udp
route 520/udp router routed
klogin 543/tcp
new-rwho 550/udp new-who
rmonitor 560/udp rmonitord
monitor 561/udp
pcserver 600/tcp
kerberos-adm 749/tcp
kerberos-adm 749/udp
kerberos 750/udp kdc
kerberos 750/tcp kdc
krb5_prop 754/tcp
ufsd 1008/tcp ufsd
ufsd 1008/udp ufsd
cvc 1495/tcp
www-ldap-gw 1760/tcp
www-ldap-gw 1760/udp
listen 2766/tcp
nfsd 2049/udp nfs
nfsd 2049/tcp nfs
eklogin 2105/tcp
lockd 4045/udp
lockd 4045/tcp
dtspc 6112/tcp
fs 7100/tcp
An Example FTP Transaction
After examining the possible client FTP commands and server response codes, let's see how this transactional system actually works in practice on Solaris. The first step is to make a connection to a remote host from the local system by using the standard client:
client% ftp server
Connected to server.
220 server FTP server (SunOS 5.9) ready.
Name (server:pwatters): pwatters
331 Password required for pwatters.
Password:
230 User pwatters logged in.
ftp>
In this simple transaction, a user logs in and enters their password, and a session is established. This involves the client program sending a session request, receiving a 220 response, sending a USER command ('USER pwatters'), receiving back a 331 response requesting a password, and sending the password ('PASS password'). If the username and password combination is correct, the session is established and a 230 response is generated by the server. Let's look at what happens when the incorrect password is typed:
client% ftp server
Connected to server.
220 server FTP server (SunOS 5.9) ready.
Name (server:pwatters): pwatters
331 Password required for pwatters.
Password:
530 Login incorrect.
Login failed.
ftp>
In this transaction, the user logs in as before, entering their password and establishing a session. This client program then sends a session request, receiving a 220 response, then sends a USER command ('USER pwatters') and receives back a 331 response requesting a password. The client then sends the password ('PASS password'), which in this example is incorrect: a 530 response is then sent back from the server to the client, and the user is left in their local client without establishing a session. However, the connect is still open, so mistyping your password can be remedied by using the following combination:
ftp> user pwatters
331 Password required for pwatters.
Password:
230 User pwatters logged in.
ftp>
Thus, the session is established, and we can proceed with retrieving or uploading files. Let's look at an example:
ftp> dir
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.58.64.22,34754) (0 bytes).
total 72573
drwxr-xr-x 13 pwatters staff 2048 Mar 27 08:43 .
dr-xr-xr-x 2 root root 2 Mar 21 18:55 ..
-rw-r--r-- 1 pwatters staff 0 Jan 27 15:42 .addressbook
-rw-r--r-- 1 pwatters staff 2285 Jan 27 15:42 .addressbook.lu
-rw-r--r-- 1 pwatters staff 5989 Mar 27 08:42 .bash_history
lrwxrwxrwx 1 pwatters staff 8 Mar 27 08:43 .bash_profile ->> .profile
drwxr-xr-x 16 pwatters staff 512 Mar 21 10:10 .dt
-rwxr-xr-x 1 pwatters staff 5113 Jan 27 15:59 .dtprofile
-rw------- 1 pwatters staff 10 Feb 23 13:18 .hist10161
-rw------- 1 pwatters staff 28 Feb 23 16:17 .hist11931
-rw------- 1 pwatters staff 20 Mar 7 15:30 .hist12717
-rw------- 1 pwatters staff 30 Feb 21 08:11 .hist1298
-rw------- 1 pwatters staff 24 Mar 7 16:05 .hist13069
-rw------- 1 pwatters staff 18 Feb 21 15:16 .hist1370
-rw------- 1 pwatters staff 8 Feb 21 15:21 .hist1395
-rw------- 1 pwatters staff 8 Feb 22 08:43 .hist15962
-rw------- 1 pwatters staff 100 Feb 28 11:15 .hist17367
-rw------- 1 pwatters staff 24 Feb 28 11:16 .hist17371
-rw------- 1 pwatters staff 16 Feb 22 11:14 .hist19318
-rw------- 1 paul staff 68 Mar 7 14:38 .hist1954
226 ASCII Transfer complete.
6162 bytes received in 0.092 seconds (65.34 Kbytes/s)
ftp>
This is the contents of the current directory. Let's say we wanted to examine the contents of the subdirectory packages:
cd packages
250 CWD command successful.
ftp> dir
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.58.64.22,34755) (0 bytes).
total 224056
drwxr-xr-x 3 pwatters staff 1024 Mar 27 08:37 .
drwxr-xr-x 13 pwatters staff 2048 Mar 27 08:43 ..
-rw-r--r-- 1 pwatters staff 2457088 Mar 17 14:37 apache-1.3.6-sol7
-rw-r--r-- 1 pwatters staff 3912704 Mar 17 14:38 bash-2.03-sol7
-rw-r--r-- 1 pwatters staff 12154880 Mar 27 08:18 communicator-v472
-export.sparc-sun-solaris2.5.1.tar
drwxr-xr-x 2 pwatters staff 512 Feb 1 07:11 communicator-v472.
sparc-sun-solaris2.5.1
-rw-r--r-- 1 pwatters staff 597504 Mar 17 16:18 flex-2.5.4a-sol7-
intel-local
-rw-r--r-- 1 pwatters staff 59280384 Mar 17 14:42 gcc-2.95.2-sol7-
intel-local
226 ASCII Transfer complete.
1389 bytes received in 0.051 seconds (26.51 Kbytes/s)
ftp>
Now, let's look at the situation in which we want to retrieve a binary and an ASCII file. An example would be a Java source file (with a .java extension), which must be transferred in ASCII mode, and a Java class file (with a .class extension), which must be transferred in binary mode:
ftp> ascii
200 Type set to A.
ftp> get test.java
200 PORT command successful.
150 ASCII data connection for test.java
(192.168.205.48,34759) (117 bytes).
226 ASCII Transfer complete.
local: test.java remote: test.java
127 bytes received in 0.02 seconds (6.25 Kbytes/s)
ftp> bin
200 Type set to I.
ftp> get test.class
200 PORT command successful.
150 Binary data connection for test.class
(192.168.205.48,34760) (431 bytes).
226 Binary Transfer complete.
local: test.class remote: test.class
431 bytes received in 0.0031 seconds (137.10 Kbytes/s)
ftp>
Although there are many more commands available in FTP, as previously discussed, these are the most commonly used commands and the responses associated with each kind of transfer.
Troubleshooting FTP
The most common mistake in configuring FTP is not to have a valid shells database (/etc/shells) on your system. Although you can insert any shell you like into the /etc/passwd file, if the shell is not registered in the database, users will not be able to log in. This is a security measure and prevents arbitrary shells with hidden features being used on the system.One of the nice features of FTP is that you can test it by telnetting to the FTP port. This will allow you to issue FTP commands interactively and examine the results. It is possible to determine, using this method, whether there is a problem with the remote server or a problem with your local client. For example, if you receive a 421 response, you know that the remote FTP server is not running, in which case you can advise the administrator of the remote machine to check the status of inetd.If your client attempts to connect to a host for a long time without receiving an acknowledgement, it's often worthwhile to check that the host is actually known through DNS. You can use the nslookup command to achieve this: if a host is not registered using DNS, you won't be able to make a connection.If the host has a resolvable hostname, then you can use any one the network troubleshooting tools like ping or traceroute to determine whether a path exists between your local client and the remote server. If no valid path exists, you can contact the administrator of the intermediate site where the connection fails.
Checking If a Host Is Up
The easiest way to check if a remote host is accessible is to use the ping command. The following example checks whether the host emu is accessible from the host dingo:
dingo% ping emu
If emu is accessible, the following output will be generated:
emu is alive
However, if emu is not accessible, an error message similar to the following will be seen:
Request timed out
If you need to determine at what point in the network the connection is failing, the traceroute command can be used to display the path taken by packets between the two hosts as they travel across the network. For example, to observe the route of the path taken by packets from AT&T to Sun's web server, we would use the following command:
client% traceroute www.sun.com
Tracing route to wwwwseast.usec.sun.com [192.9.49.30]
over a maximum of 30 hops:
1 184 ms 142 ms 138 ms 202.10.4.131
2 147 ms 144 ms 138 ms 202.10.4.129
3 150 ms 142 ms 144 ms 202.10.1.73
4 150 ms 144 ms 141 ms atm11-0-0-11.ia4.optus.net.au [202.139.32.17]
5 148 ms 143 ms 139 ms 202.139.1.197
6 490 ms 489 ms 474 ms hssi9-0-0.sf1.optus.net.au [192.65.89.246]
7 526 ms 480 ms 485 ms g-sfd-br-02-f12-0.gn.cwix.net [207.124.109.57]
8 494 ms 482 ms 485 ms core7-hssi6-0-0.SanFrancisco.cw.net [204.70.10.9]
9 483 ms 489 ms 484 ms corerouter2.SanFrancisco.cw.net [204.70.9.132]
10 557 ms 552 ms 561 ms xcore3.Boston.cw.net [204.70.150.81]
11 566 ms 572 ms 554 ms sun-micro-system.Boston.cw.net [204.70.179.102]
12 577 ms 574 ms 558 ms wwwwseast.usec.sun.com [192.9.49.30]
Trace complete.
If the connection was broken at any point, then '*' or '!' would be displayed in place of the average connection times displayed.
Enabling FTP Access
Now that we have examined the most common uses for FTP, we will now investigate how to configure the FTP daemon. The FTP server in Solaris is installed by default during configuration and package copying, during the initial installation or upgrade process. By default, the FTP server and protocol will also be active after installation. You can check the status of the FTP server on the local system by checking whether the FTP service is enabled in the services database, and in the configuration file for the inetd superdaemon:
server# grep ftp /etc/services
ftp-data 20/tcp
ftp 21/tcp
tftp 69/udp
server# grep ftp /etc/inetd.conf
ftp stream tcp nowait root/usr/sbin/in.ftpd in.ftpd
# Tftp service is provided primarily for booting. Most sites run this
#tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd
-s /tftpboot
We can see that FTP is both defined as a service (ftp 21/tcp) and as a daemon that runs from within the Internet superdaemon (/usr/sbin/in.ftpd). As long as the Internet superdaemon is started up during one of the single or multiple user init states, the FTP service will start. If you ever want to disable the FTP service, you need to comment out the appropriate line in both /etc/services and /etc/inetd.conf. You can do this by entering a hash character (#) in front of the appropriate line:
#ftp 21/tcp
#ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd
You can also check the process list by using the command ps -eaf | grep inetd to verify that the Internet superdaemon is running at any point in time.
