This repository has been archived by the owner on Sep 10, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
FAQ
127 lines (99 loc) · 5.3 KB
/
FAQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
1) What are the best values for --tftpd-timeout, --retry-timeout and
--max-thread ?
There is no absolute answer to that question. It is highly dependent
of your personnal setup. Here's an explanation of what they mean and
how to tune them.
--tftpd-timeout controls how much time the server will wait for an
incomming connection before killing the main thread. If you use small
number, the server will be respawned by inetd when a new query
arrives. If number is high, atftpd will behave more like a standalone
server in that it will always receive queries directly. When booting a
whole cluster, the first tftp request will start the daemon and have
higher latency. All other clients will be handled directly by the tftp
server. It is a good idea to set the timeout high enough so that the
main thread won't hog your system killing itself and respawning all
the time.
--retry-timeout controls how much time the server waits before
retransmitting a packet. If you expect some lag on the network (when
the network is under high load), it is a good idea to increase that
value. Note that the client's delay must be taken into
consideration. The client can set the server delay too, and it
overides the --retry-timeout value.
--max-thread controls how many simultaneous client may be served. This
limit depends on your server's performance. It also depends on the
maximum load you are willing to put on the server. For exemple, this
server may have other things to do, and you want to limit the number
of clients booting at the same time to 10. The maximum number of
threads is also throttled by the available bandwidth of the network
and server, because packet cannot be processed fast enough and there is
a maximum rate at which servers may be started. But this is not a desirable
condition and --maxthread should be set to avoid that.
2) Why do I get "recvfrom: Connection refused" in my log file?
That indicates that either your server or network can't handle all the
packets fast enough. What happens is the following:
- client sends a RRQ (read request)
- server starts a thread (A) that sends a DATA packet
- the client times out and sends a second RRQ
- server A sends the whole file
- client and server thread A both exit normally
- server finally starts a second thread (B) for the second RRQ
- the server thread sends a DATA packet to the client
- the client isn't listenning anymore, we got a connection refused.
Solution:
a) increase timeout on client and server side
b) reduce the number of concurrent thread allowed
c) do nothing, it's not harmfull at all.
3) How can I boot a simple image from the network?
A boot from LAN setup requires the following on the server side: a dhcp
server, a tftp server (atftpd), a working pxelinux config, a kernel image
and a root file system image.
You can get documentation on how to configure the dhcp server to work with
pxelinux from the pxelinux and dhcp documentation.
For atftp to work out of the box, be sure to have the following line in your
inetd.conf and to restart the inetd daemon:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot
You also need to have /tftpboot world readable.
The pxelinux configuration is the same as syslinux. Documentation for it can
be found in the syslinux package.
The configuration file for pxelinux will tell it the name of the kernel and
file system images to download. It is very important that you tell the kernel
image where to get its root file system with rdev like this for example:
rdev image /dev/ramdisk
You can find detailed information on how to create a filesystem image in the
Bootdisk HOWTO (www.linuxdoc.org).
On the client side, you need to have a boot ROM. Have a look at Etherboot
(www.etherboot.org), NetTools and Nilo (www.nilo.org) to find out more
information about this if you need to burn one.
After you got all of these setup, you should see the client attempt to get
an IP address on boot, download pxelinux.bin, then download the kernel and
filesystem images and boot from it.
4) I followed the above steps and it still fails to boot!
Try putting log verbosity at high in the concerned programs on the server side
and see if something fails or if you get the requests at all. You should see
dhcpd give a lease to the client, if it doesn't, your dhcp configuration is
faulty. You can also monitor the activity on the network to track down the
problem using tools like tcpdump or ethereal.
5) How do I setup multicast stuff?
- Make sure your client and server support multicast.
- Make sure you server routing table know what to do with multicast addresses.
You need to do something like this:
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
- Make sure your network is working by testing with atftp client against
atftpd server
That's currently all that I've made working folks. I've never tried a multicast
boot ROM or boot loader yet.
6) What inetd or xinetd configuration should I use?
Something like that for inetd in /etc/inetd.conf:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd <insert options>
For xinetd, in /etc/xinetd.conf:
service tftp
{
socket_type = dgram
protocol = udp
wait = no
user = nobody
server = /usr/sbin/in.tftpd
server_args = <insert atftpd options>
}
This is the basic stuff. Read inetd or xinetd man page for more specialised
configuration.