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
|
sitesummary
===========
More information is available from
<URL: http://wiki.debian.org/DebianEdu/HowTo/SiteSummary >.
Sitesummary generated Munin configuraiton
-----------------------------------------
Sitesummary can be used to generate Munin configuration to collect
statistics from all sitesummary clients with the Munin packages
installed. To enable it, install the munin package and make sure
/etc/sitesummary/collector.cfg include 'MUNINDIR=/etc/munin' to get
sitesummary to replace the default munin configuration with the
generated one. Running these commands as root normally does the
trick.
aptitude install munin munin-node
echo MUNINDIR=/etc/munin >> /etc/sitesummary/collector.cfg
sitesummary-client
/etc/cron.daily/sitesummary
Sitesummary generated Nagios configuration
------------------------------------------
Since version 0.0.51, there is experimental code in sitesummary to
generate Nagios configuration based on the collected information. To
enable this, install nagios3 and nagios-plugins-standard, edit
/etc/default/nagios3 to include
'NAGIOSCFG=/etc/nagios3/sitesummary.cfg' and run the sitesummary cron
job. Running these commands as root normally does the trick.
aptitude install nagios3 nagios-plugins-standard
echo 'NAGIOSCFG="/etc/nagios3/sitesummary.cfg"' >> /etc/default/nagios3
sitesummary-client
/etc/cron.daily/sitesummary
/etc/init.d/nagios3 restart
The current version of the code run all Nagios checks locally, so it
only work on a single machine. The plan is to change this to use NRPE
to work with a network of machines.
Design draft
------------
system to collect key info about all the machines on a site, to help
the sysadmin keep track of a lot of hosts.
Should be capable of handling both thin clients and "real machines"
- two package, one server sitesummary and one client sitesummary-client
- the client submits information to the server using HTTP put. It
include the list of files it intend to submit, to detect deleted
files.
- the HTTP connection is either using SSL, or the file(s) transfered
are GPG encrypted. (figure out key exchange system)
- the client submit a set of files and output from commands with hw
information etc (need plugin system to make it submit more files)
- lspci
- lsusb
- dmidecode
- uname -s / -m / -r / -v / -o
- ifconfig -a
- public ssh host key
- /etc/debian_version
- dpkg -l
- /etc/apt/sources.list
- /etc/fstab
- /proc/cpuinfo
- /proc/meminfo
- the server track changes done to the files (some version control
system like rcs?) on each host, and make summary report on the
number of individual machines reporting to the server
- how do we identify machines? MAC address could work (ip -s -f link
maddr - which when several interfaces?). IP addess will not work
for thin clients on private networks behind two different servers.
the linux hostid command is only using IP address and is useless.
Can not generate random key stored on the file system, as this
would give all thin clients on a server the same ID. dmidecode
serial number might work for some models, but others have the same
serial number on several machines.
- ideas for use of this info
- machine count, grouped by os/kernel/etc
- can generate a list of host keys for distribution to the clients
- can generate dhcp MAC<->IP mapping
- can generate lts.conf files for the LTSP clients
The server can either be a CGI script, or listen on some port on its
own.
The client should be a platform independent script with as few
dependencies as possible, to make it lightweight and easy to install
on all machines. (perl, python, /bin/sh?)
Should the client know which files to report, or should the server be
able to affect it? Can cfengine, nagios or munin be used for this
instead?
|
