CSIM Technical Notes

It seems that the new release of ZeroShell takes quite some time to reload the rules once a rule is added or changed. It may take a matter of minutes.

Never ever attempt to restart the iptables service manually, it would restart the firewall with very limited configuration, leaving the network widely exposed.

AIT has a print from anywhere function working with the software PaperCut that associate print quota to the users. CSIM also has print quota. Both system must be synchronized.

The synchronization is set in two steps: once a night around 00:55. PaperCut sends emails to postmaster@cs.ait.ac.th with the detail of the pages printed by the users of each FoS. Then around 10:25 we push the new credit available for each user.

Synchronization from PaperCut to CSIM

This is the most tricky part! Once a night postmaster@cs.ait.ac.th receives one email for each of our FoS. The emails are forwarded to on@cs.ait.ac.th and processed by a procmail receipt that call the script ~on/Ldap/procmail-extract-papercut.

This script checks that the email has a correct contents, that a .csv file is attached with the proper name. The attachment is saved into a file and the script ~on/Ldap/do-report-papercut.pl is called on the file.

The second script is more complicated. As reports are sent once a night, if one report is lost, some data is missing. The script keeps track of the last report that has been processed in the file ~on/Ldap/timestamp-papercut.db. There is one timestamp for each FoS.

Daily reports are covering the period from 00:00:00 to 23:59:59 the previous day. So every new report should start exactly one second after the previous one. The period covered by a report is written in the headers of the .csv file.

The script takes into account gaps in the report coverage as well as overlaps. If an error occurs in the period sequence, the file is not processed; instead, an email is generated that highlight the conflict and suggest to generate a report manually, the manual report can then be processed by that same script.

Once the period of the report has been validated, the print usage for the users listed in the report are updated accordingly.

The script also generates a list of users that are known in PaperCut but not in CSIM LDAP. That should only happen if a user has been wrongly associated with a FoS; that can only be rectified at PaperCut level.

Finally, the script compares the cost calculated by PaperCut and the cost computed by CSIM. If there is a discrepancy, it suggests that the rates in LDAP ou=Ricoh cost, ou=Resources does not correspond to the cost used by PaperCut. The costs should be updated in LDAP; there are 3 records to update for Black&White, colour and the ration B&W/colour. This is not a blocking error.

How to generate a report manually?

When there is an error in the synchronization from PaperCut to CSIM, a manual report must be generated to correct the error.

You must connect to PaperCut web administration interface then go to the report menu. Chose to create an Ad hoc User Printing Menu.

You have to select the group in the form of SET/ICT/FoS and enter the starting and ending date and time for the report. For the reason explained above, the >i>date and time must be very strict else the reports will be deemed not consecutive.

Once the .csv file has been saved, you can apply the script ~on/Ldap/do-report-papercut.pl on the file.

Synchronization from CSIM to PaperCut

The synchronization is much simpler in this direction. Every day at 10:25 the script ~on/Ldap/update-account-papercut.pl is run via cron(8).

Any user that is in CSIM LDAP but not in PaperCut are either a mistake (a user from another FoS where the attribute csimIsCsim is not False) or a deleted user. In either case, setting csimIsCsim to False in LDAP for that user will solve the problem.

The script goes through the list of users in PaperCut and in LDAP and computes the number of pages printed and the remaining credit, The credit is then updated in PaperCut. Deleted users in LDAP have a credit set to zero.