Thank you, David, that's very kind of you.  I hope you do get the opportunity to do some documentation of the configuration files (maybe you could delegate this to somebody you trust with the source code?) but I know you have more important projects already in progress.

I solved my immediate problem with a little gawk code that changed all the zeros to ones in the 8th byte (ignoring any non-zero values) for all my users and sites, and visiting the people with oddball values personally and showing them where to set the auto-timezone in their GUI.  We're all copacetic now.

When I make a default PMAIL.INI template for my users, I start with a fresh empty H:/PMAIL folder and run the current version of Pegasus, and answer the opening questions with a set of known unambiguous values.  Then I replace the occurrences of those values within the newly created configuration files with numbered tags (like this: %1, %2, %3.1, etc.) to create the template files.

When a new user is created, the template files are processed to place the appropriate information in the appropriate places (this is just one of many processes that are necessary to create a new user; we have to provision the phone system, establish 802.1x access policies, etc. etc. etc. ad nauseum) using a little script like so:

prepmail.sh homeserver HJSimpson "Homer J. Simpson"

The prepmail script will substitute homeserver for %1, and  HJsimpson for %2, and "Homer" for %3.1, and so forth.

I use a single SMTP definition and a single TOOLBAR.PM on each site's homeserver and use symbolic links for each user; that way I can change them in one place and have everyone changed at once.

A new user's password is flagged as pre-expired on the POSIX side, and when that person logs in the first time, they are redirected to a web page (which they can't escape without rebooting) which makes them set a strong password.  That password is encrypted and written into the users' IMAP.PM file (it's also entered into LDAP, and some other places, with the appropriate encryption for each place).

It's conceptually elaborate, but there's really very little code that is very easy to maintain, and it saves many man-hours every year as well as making account provisioning painless for users and system administrators.

I have a similar process that lets our sysadmins painlessly change a users' name (usually due to marriage or divorce) and preserves all their files and email intact.

(This topic was moved from the Mercury support forum, where I stupidly mis-posted it yesterday.)

I work for a non-profit organization with around 400 Pegasus Mail users. Our installation has grown over the last decade to include auto-distribution and setup of individual users' pmail accounts. We don't run Novell products or Mercury, though we did have Novell once upon a time. The core mailservers are linux.

Our passwords to our IMAP servers, SMTP servers, SMB/CIFS filesharing, web servers, telephone system, databases, POSIX systems etc. are all single-sourced from a massively redundant LDAP store and co-ordinated/distributed with samba+OpenLDAP.

My users are not familiar with manipulating Pegasus options, and in fact are discouraged from spending time exploring Pegasus configuration. They don't even know how to enter their passwords, since their normal scheduled password change automagically edits their IMAP.PM for them.  If a deficiency in the standard configuration is reported, I mass-edit all users PMAIL.INI (or whichever) files to correct the problem, and everyone happily goes about their business.

This is very cost efficient. It makes version upgrades go smoother, too. Re-writing 400-500 PMAIL.INIs usually only takes a few minutes, and I do it after hours.

But I need to turn on auto-timezone for all my users, and I'm having trouble understanding the byte-map. When I turn it on, the "Default settings values" in PMAIL.INI changes from 2200001B000100001200000000000000 to 2200001A000100001200000000000000 (8th byte changes from A to B). When a cow-orker of mine turns his auto-zone on, the same value changes from 00000020000140400000000000000000 to 00000021000140400000000000000000 (8th byte changes from 0 to 1). We are not only running the same version of Pmail (4.41) we are actually running the same executable - we all do, it's on a network shared drive (again making upgrades smoother). This is somewhat baffling...

Does anybody know how to set auto-timezone by directly manipulating the PMAIL.INI file? Using the GUI is needlessly painful for the users and impractical for the organization.  I just need to know what bits to tweak, and then I can fix timestamping for all our users simultaneously.

Good question but as far as I know there is no tool to manipulate the numbers in the pmail.ini file.

I'd wish to have an exhaustive list of all these parameters so that I could (or someone else) create a tool to manipulate these strings of numbers to change the time zone but also all the others parameters recorded in these strings.

A tool like this could be run in a batch file to correct the setup of all my users (I have almost 1500 users).

Regards

I don't need a toolset, I just need to know what the setting is.  Pegasus's configuration is in pure ASCII text files for the most part, which shows David's a whole lot smarter than the average bear.

My users' configuration files are kept in their network home directories on a samba server, so I can trivially mass-edit them.  If I want to survey what they have in their "Default settings values" right now, I just type this at a root prompt on the server:

find /home -path "/home/*/PMAIL/PMAIL.INI" -exec grep 'Default\ settings\ value' {} \; |cut -b'42-132' |sort |uniq -c

That gibberish will output all the unique settings in our enterprise, sorted and with counts prepended to each one, in less than a minute.  I can use similar methods to conditionally modify each file on the fly, and I've done so quite a few times in the past.

I know that the eight byte of the "Default settings values" determines whether auto timezone is in effect.  Unfortunately, there's something else non-obvious going on, since this byte does not get a simple "on or off" value like one would expect.

Phillipe, I think you might be able to use Han van der Boegarde's solution detailed here:

http://community.pmail.com/forums/post/2548.aspx

If that deep link doesn't work, search for Han's Mercury support forum post tagged with "pmppkg preference file".  Basically, there's a way you can email settings to your users.  It won't work for me, because I've trained my users never to trust email that might modify their systems, and because I need a non-interactive solution, but it might help your situation.

There is a partial listings of the meanings of some of the INI settings here, but it doesn't have the auto timezone setting I need.

Hello!

I have just tested this myself. As I am no prgrammer, all I can do is quick comparison of the pmail.ini before and after changing the setting for the automatic timezone value.

To make things more complicated, I have found out that my settings change in different way: from "3" to "2" (and vice versa). "3" means that the automatic settings is turned on, whereas "2" means that it is turned off.
As far as I understand that, I cannot say anything about the values themselves, but about the relative interference: the difference between turning on and turning off the automatic timezone is -1 / +1 (provided that digits are used). If the automatic timezone is turned off and you want to turn it on, you seem to have to add +1 to the current value; if the automatic timezone is turned on and you want to turn it off, you probably have to substract 1 (hence -1). There seems to be a similar calculation in case letters are used.

I do not know about grep, but could grep (which is one of the famous text-manipulating UNIX tools, I think) do a calculation (+1 / -1) instead of a simple substitution?

Note that you would have to edit all identities your users have created; each identity has its own setting for the automatic timezone value (to the best of my knowledge).

Thank you for the info, Thomas.  This is what I am seeing right now in my users' PMAIL.INI files (selecting out only the 8th byte of the "Default Settings values" word).

366 identities with a value of 0
872 identities with a value of 1
    8  identities with a value of 2
    7 identities with a value of 3
    2 identities with a value of 4
    2 identities with a value of 8
    2 identities with a value of B

The parse I'm using doesn't care how many identities are in each INI file (I have at least 40 in my own, but most of my users only have one).  It's hitting archived ex-employees, too - I don't really have more than 1000 users.

 I agree with you about the +1 / -1 ... I was hoping that I could simply test to see if the number was odd or even (and add one if it was zero or even) but the A and B kind of throw that idea out the window.

The best tool for large-scale manipulations of these kinds of things is the GNU awk, which runs on multiple OSes and is very simple and powerful.  Here's how I'm going to switch all the zero entries to ones:

gawk '/Default\ settings\ value/{if (substr($5,8,1)=="0"){$0=sprintf("%s %s %s%20s %s1%s",$1,$2,$3,$4,substr($5,1,7),substr($5,9))}};{print}'

I'll wrap that in a little shell code to find each users' PMAIL.INI and save the old version with a different extension.  You can do the same thing in perl, too, but the code gets even more difficult to understand and perl has a bigger footprint than gawk.

I think I'll be able to handle this by programatically switching all the zeros to ones, and then physically visiting the desks of each of the 19 users with strange values like A or 8.  It's a good excuse to go chat with the users anyway and make sure they are all happy.

 I'd still like to know what's going on with this variable, though... most of the PMAIL settings are much more programmer-friendly.

[quote user="Medievalist"]

I'd still like to know what's going on with this variable, though... most of the PMAIL settings are much more programmer-friendly.