Participants: DanielAllen, Dave Gawley; advice by FraserGunn.

Demo at: http://lurch.uwaterloo.ca/cyclades/

As per Dave's requirements, the:

Overall Design

Database Design

• uses mysql database on database.cs and can log into the terminal server to read and set configurations.

• HOSTS table: records the following information for each host being maintained on the CTS (all 1:1 information):
  • HOSTID (autogenerated)
  • HOSTNAME (DNS name of host)
  • CLASSID (such as core.cs,plg,bsd,..)
  • CONSOLEID (console name: DNS)
  • PORT (port on console)
  • SERVICES (being run on the host, such as web,ssh,...) this is kept in a separate table HOSTSERVICES for easier normalization.

I will use additional tables for:

• SERVICES
  • SERVICEID
  • NAME
• HOSTSERVICES
  • HOSTERVICEID
  • SERVICEID
  • HOSTID
• PROPERTIES
  • PROPERTYID
  • NAME
• HOSTPROPERTIES
  • HOSTPROPERTIESID
  • PROPERTYID
  • HOSTID
• CLASS
  • CLASSID
  • NAME
• CONSOLE
  • CONSOLEID
  • NAME (DNS)
• LOG
  • TIMESTAMP
  • (columns from HOSTS table)
  • authenticated user
  • comments

Functionality / Code Design:

• tool will be used to:
  • generate configurations in a form to be passed to the CTS to be executed (automatically via ssh)
  • produce a webpage which will display summary information from the db

• tasks we might want to do:
  • list hosts on console cts1.cscf
  • list services on host foobar
  • list hosts running service X

Properties

The only property identified so far is "requires data by IP address instead of name." The design should have the flexibility to add other properties; these are different from Services offered or Class the host is in (although they could supplant/suppliment both lists).

See CycladesConfigurationProjectData for the list Dave/Dan have started giving me (hosts that require data by IP).

Design References

https://www.math.uwaterloo.ca/mfcf/internal/procedures/access/cyclades.html

example configuration file: cscf.cs:/software/cyclades/spool/config_files/20050519/cts2.cscf/etc/portslave -

we want to load/save the data at the very bottom of that file.

Design Notes

a cscf /etc/portslave file has the following format:

s17.serverfarm  services103.math
s18.serverfarm  descartes-csw4
s19.serverfarm  descartes-csw5
s20.serverfarm  pilatus.cs
s21.serverfarm  fs101.math
s22.serverfarm  fe02.math
s23.serverfarm  cscf.cs
s24.serverfarm  NC

s20.speed       38400

Hm, but that data is a bit different on, for example, cts2.mfcf, which has extra columns:

#Port           Hostname             Cable#  Comments

s17.serverfarm  NC
s18.serverfarm  neutral.math            -    no response
s19.serverfarm  cacr2.math           1101
s20.serverfarm  general.math         1116
s21.serverfarm  theano.math          1102
s22.serverfarm  cemc-dev.math           -    was 1103, dantzig
s23.serverfarm  pythagoras.math      1184
s24.serverfarm  lanyard.math         1119    didn't verify cable #

this file also has comments with datestamps, prior to the definitions.

• So our db should handle comments as well, in some form; and possibly cable number separately as well.
• We should also keep a transaction log, possibly with the comments; including date.
• how do I get the services that are running? An obvious way is to run nmap on the host itself, though that may miss non-standard services. perhaps that list isn't auto-generated, or necessarily auto-complete.

Initial CTS Setup Notes

[this should be merged with the instructions at the tail end of https://www.math.uwaterloo.ca/mfcf/internal/procedures/access/cyclades.html, which is an older, only slightly stale, set of instructions].

1. cts came with: power cable, bag of port adapters, "user guide" (more like quick-start guide) and CD of documentation. The CD's reference manual was quite helpful for the remaining information (such as editing the firewall).
2. [This step turns out to be out of order; should have connected from console first]. Briefly plugged cts into network on 15 vlan. It automatically responded on the appropriate hostname/IP pair, so I assume its MAC address was already recognized by the DHCP server.
   1. Connected to its webserver, and used the user/pw combination from the user guide. Stayed logged in long enough to change root pw.
   2. ran nmap -p 1-1024 cts3.cscf to find out what services are running. PORT STATE SERVICE 22/tcp open ssh 23/tcp open telnet 80/tcp open http 111/tcp open rpcbind 443/tcp open https
   3. Logged in via ssh. It used the original root pw. Different web and shell root users! changed root pw.
   4. after saveconf, turned device off and on, saw that it preserved changes. Turned off because I didn't know what firewall settings were.
3. Connected via console port on cts and serial port on computer. ran 'minicom' configured with speed=9600. booted cts; it gave me a nice booting message.
4. logged in as root; followed instructions of banner on login: edited /etc/hostname, /etc/hosts, /etc/resolv.conf, and looked at /etc/network/st_routes and /etc/portslave/pslave.conf. Ran signal_ras hup to activate changes. saved configuration changes via saveconf.
5. noted inetd is only running telnet, so turned inetd off.
6. added my ssh key to .ssh/authorized_keys ; verified that it uses passwordless authentication. Aside: when I rebooted, it seems to have reset the shell root password to something other than what I set it to, or the default. Googled for instructions on resetting it; the answer is when it first boots, the console displays "Linux/PPC load: (...)". Press space, enter the word 'single' and hit enter. You can then reset the root password normally with 'passwd; saveconf'
7. next, worked on firewall.
8. adrian tells me the existing configurations are all saved via an xhier package: cyclades-1. /software/cyclades/spool/config_files/20050519 has the most recent config files; sorted by cts number.
9. copied cts2.cscf/etc/network/firewall to cts3 and ran saveconf
10. that didn't work; on reboot, iptables-restore segfaults.
11. the short story is: the old configuration was with ipchains. The new cts uses iptables.
    1. conversion process was relatively straightforward (see below).
    2. ran individual commands to set up tables and chains; then deleted mistake entries; then saved tables via iptables-save >/etc/network/firewall-new. Edited the file with vi to fix a few mistakes; and renamed over /etc/network/firewall. ran saveconf /etc/network/firewall and rebooted.
    3. connected to network again; tested firewall works properly.

ipchains to iptables conversion notes

• 'DENY' becomes 'DROP'
• '80:80' becomes '--destination-port 80' (must come after -p which specifies protocol).

• iptables -L will try and use reverse DNS translation, so you need '-n' to prevent that.

-- DanielAllen - 08 Jun 2005