jeeason’s blog

Use postconf -e as the zimbra user to edit /opt/zimbra/postfix/conf/main.cf. These changes probably won’t stick past an update. If you edit the file instead of adding them with postconf -e they won’t stick past a zimbra restart, or config changes made from the gui.

These are intended to allow local and authenticated mail, including plaintext auth, and reject everything else.

postconf -e smtp_sasl_security_options=

postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

postconf -e smtpd_sasl_auth_enable=yes

postconf -e smtpd_tls_auth_only=no

Using postconf works better than zmlocalconfig, according to: http://wiki.zimbra.com/index.php?title=King0770-Notes-Postconf_or_localconfig

This can be fun.

In zimbra:
zmmsgtrace -F 10.85.50.33 -t 20091118

They may also show up in logs:
grep “10.85.50.33″ /opt/zimbra/log/nginx.access.log
grep “10.85.50.33″ /var/log/zimbra.log

However, zimbra outlook connector users are hard to get an IP for. These are easier to look up in Novell.

1. grep -A 10 “10.85.50.33″ /etc/dhcpd.leases

2. If you get a client-hostname, use that to do a Find in console one on terminals (select SCAD/CAMPUS) then look at the last logged in user. Otherwise you can use the last 6 chars of the mac address, e.g. *92:a3:e6* to search it.

Seems like I should document this…

http://network.scad.edu/printers is hosted on scad-ns-1. The pages are generated by a script /usr/local/printerpage/printerpage.pl running from cron every 15 minutes (last time I looked). It reads the install link page for all printers from each of the zenservs and sorts the printers out by building. Printers named something containing LB|LAB|PLOT|PLOTTER are assumed to be lab printers and listed under http://network.scad.edu/labs. Printers named ATL… or ATLS… are assumed to be Atlanta printers.

The pages are generated from either header.txt or labhead.txt + footer.txt. Both header files contain a list of buildings that should be updated when a new building is added (if it’s in one but not the other, please add the line to both and comment it out appropriately). printerpage.pl also contains a list of buildings and their abbreviations that needs to be edited. Pages are not overwritten if the building is renamed/removed and have to be deleted by hand.

There is a list of “secret” printers in printerpage.pl in the %skips hash for things like check printers or photo printers. I hand-edited the special page to add or remove these - it was password protected last time I looked at it. These are left off the page. I’m not sure it’s still in use.

Printers that don’t belong to a building in %buildings also aren’t listed. This was so various printers called TEST wouldn’t show up on the pages.

If the script is unable to grab the printer list from one of the zenservs, it quits without modifying anything and emails me.

To find a user by IP address: (depending on how they connected)

grep “client: 10.130.100.99,.*login” /opt/zimbra/log/nginx.log

New setups go into /optim/trans/dfiles/crt/iptxninterface. You will need to know: loop, address, terminal serial number (can be anything, we use the terminal # with one digit trimmed) and a random key, which can be anything and should be unique for each terminal.

Keys can be generated on linux with:

od -An -N16 -x /dev/random

After editing the file, su - poller and run ld_fdi_tbl. This will generate a file /optim/trans/dfiles/crt/iptxninterface.lst. Check it for errors!

This error doesn’t seem to be significant: *ERROR* Reader for loop 0 addr 10 is not CRT READER type

reference page: http://kb.blackboard.com/display/~bburch/MDTs+Adding+MDTs

First grep /optim/trans/dfiles/crt/verifone for the serial number (or expect very strange results if two devices have the same serial - don’t go there).

If it isn’t there already, add the new device at the end of the file. The general format is:

Line 1:

|1|811032708|712|007|12|100|100|5256266||0|0|1|3|1|tranz 380×2|Rays Cafe

field:   1   2   3   4   5   6    7    8/9/10/11/12    13        14

change these:

1: terminal serial #

2. Number

3. Loop

4. Address

5. + 6. Tender types - these should pretty much stay the same

7. Modem number for dialup - put a 9 in front to test from campus

8. + 9. + 10. + 11. These pretty much stay the same.

12. Tip line printed on receipt - 0 = no, 1 = yes

13. Terminal type

14. Business name

The lines starting with |2| define what will print on the receipt. These need the terminal’s serial in the second field.

when converting the calendar of a former account into a resource:

1. create the account under mailserv.scad.edu/authentication_only.

2. create it as a resource from the zimbra admin console.

3. load the calendar. This last part might be interesting.

If it has the same name,e.g. somecalendar

curl -u admin:password –data-binary \@/home/jeeason/somecalendar.ics ‘https://sav-mta:7071/home/somecalendar/Calendar?fmt=ics’ –insecure

If it has a different name, e.g. newcalendar, the file needs some editing or newcalendar won’t own any of the events.

X-NSCP-CALPROPS-RELATIVE-CALID:newcalendar@scad.edu

X-NSCP-CALPROPS-RELATIVE-CALID:newcalendar@scad.edu

:%s/somecalendar/newcalendar/g

:%s/^ :newcalendar/ :newcalendar@scad.edu/g

If needed you can empty the calendar out like this:

su - zimbra -c ‘/opt/zimbra/bin/zmmailbox -z -m somecalendar emptyFolder /Calendar’

This was a two-day session on system administration with a group discussion format, led by two experienced system administrators, with eight students participating. Both the instructors teach for other events such as the Usenix LISA meetings. The class covered a broad range of topics:

• What is a sysadmin?
• Career survival skills and career development
• Configuration management
• Ethics
• Monitoring
• Policies and the sysadmin
• Professionalism
• Security
• Documentation
• Disaster recovery
• Communication skills and techniques
• Project management
• Effective change management
• Becoming a master

The class was an overview - any of the topics could have taken a couple of days by itself. The instructors would introduce a topic and discuss how they felt it should be handled, then open it up for discussion by the participants. This format turned out to work well because everyone would comment on how they had approached a problem and how well the approach had worked.

I found several of the topics very timely. For example, Network Services is in the process of testing our disaster recovery plans, so it was useful to hear recommendations on how to set up a good DR plan (our plan is a good one - we have a written plan that states exactly what we will need to recover, and we test it to make sure it works). I also heard some interesting anecdotes about companies that have to do “extreme” DR plans. One of the major cruise lines has several locations around the Caribbean and could potentially be hit by hurricanes at more than one site. Therefore, they have five datacenters, all of which have hot and cold spare servers in place, and can manage business-critical functions with only two of five datacenters operational.

Other discussions that I found particularly valuable were on monitoring services (mrtg, nagios, centralized syslog monitoring) and configuration management (bcfg2, puppet, cfengine), and of course security. I don’t often have access to a room full of experienced unix sysadmins, and it was very interesting to be able to ask why the attendees had chosen one setup over another. However, all the topics were useful in one way or another.

The first session I went to was a tutorial on using Moose, which is an object system for Perl. Perl does have object-oriented features, but the implementation leaves something to be desired - the presenter described Moose as “syntactic sugar for Class::MOP”. After that I went to sessions on avoiding project disasters, user interface design, and one on controlling an Ajax interface with HTTP.

The afternoon sessions closed out the conference. First up were two hours of lightning talks, which are 5 minutes per presenter on something interesting (or funny). The closing keynote was by two guys from Google, on how to work with users and design interfaces.

I went to a couple of talks about modules for interfacing with databases in the morning, as well as a talk that I found particularly useful about Regexp::Common. That’s a good module for matching things like URLs that can be tricky. Another one found interesting was on modularizing code.

In the afternoon I went to the talks in the testing track. TAP (Test Anything Protocol), Perl::Critic and Perl::Tidy were mentioned repeatedly. There was quite a bit on testing web pages, and one presenter discussed ways to automatically generate test scripts.