Difference between revisions of "Einstein Status"

From Nuclear Physics Group Documentation Pages
Jump to navigationJump to search
Line 4: Line 4:
  
 
# Check all services einstein currently provides.  Locate as many custom scripts, etc. as is reasonable and label/copy them.
 
# Check all services einstein currently provides.  Locate as many custom scripts, etc. as is reasonable and label/copy them.
## Network interfaces. eth1 is up as the UNH interface, while eth2 doesn't seem to be working as the farm interface. Pings/traceroutes go out but responses don't come back. I've tried tinkering with iptables but that doesn't seem to be the cause. Configs are as described in [[Servers and Workstations]].
+
## Network interfaces. eth1 is up as the UNH interface, while eth2 doesn't seem to be working as the farm interface. Pings/traceroutes go out but responses don't come back. I've tried tinkering with iptables but that doesn't seem to be the cause. Configs are as described in [[Servers and Workstations]]. 2/14/2008: I think the best bet for now would be to just use farm over the interface that works, and set up VLAN for unh. I'll switch the cables around and see how it goes.
 
## [[Iptables]]
 
## [[Iptables]]
 
## [[DNS]]
 
## [[DNS]]

Revision as of 13:41, 14 February 2008

Massive amount of deployment documentation for RHEL 5

Remade the RAID5. Will redo the software, but if the RAID dies again we should think of a different machine to sub for einstein.

  1. Check all services einstein currently provides. Locate as many custom scripts, etc. as is reasonable and label/copy them.
    1. Network interfaces. eth1 is up as the UNH interface, while eth2 doesn't seem to be working as the farm interface. Pings/traceroutes go out but responses don't come back. I've tried tinkering with iptables but that doesn't seem to be the cause. Configs are as described in Servers and Workstations. 2/14/2008: I think the best bet for now would be to just use farm over the interface that works, and set up VLAN for unh. I'll switch the cables around and see how it goes.
    2. Iptables
    3. DNS
    4. LDAP
    5. Postfix
    6. AMaViS
    7. ClamAV
    8. SpamAssassin
    9. IMAP cyradm localhost gives "cannot connect to server". This all seems to be sasl-related. It'd be probably be easy if there was a way to have cyrus use PAM. LDAP and sasl Nevermind, that has to do with using SASL to authenticate LDAPsaslauthd -v lists pam and ldap as available authentication mechanisms, and /etc/sysconfig/saslauthd has an entry "MECH=pam"…! What am I missing? Tried making a new "mail.physics.unh.edu.crt" for tomato, but couldn't because that would have required revoking einstein's cert of the same name. Tried using the "tomato.unh.edu.crt" and "tomato.unh.edu.key", but is giving the same results as the "mail.physics.unh.edu.*" copied from einstein. Tried using tomato's UNH address instead of hostname: same result. I'm able to login using the imtest program, but the server doesn't send the same messages as shown here. Let's try Dovecot instead. It supposed to be simpler to maintain and is supported by RedHat.
    10. /home
    11. Samba If anyone needs samba access, they need to find us and have us make them a samba account. No LDAP integration.
    12. Web?
    13. Fortran compilers and things like that? (Also needs compat libs--Nope, tomato is 32-bit.)
  2. Switch einstein <-> tomato, and then upgrade what was originally einstein
  3. Look into making an einstein, tomato failsafe setup.