I'm trying to configure my mail server. The MTA is postfix and in some configuration options is used hash in front of some statement.
example:
alias_maps=hash:/etc/aliases
Whay is it for?
Postfix doesn't use the flat ascii files (well, mostly, that is), but uses a "hashed" for that allows quicker lookup/retrieval.
hash/btree are BerkeleyDB-type file based "databases".
This means, that Postfix doesn't actually use the file /etc/aliases, but rather /etc/aliases.db which is in turn generated by the "postalias hash:/etc/aliases" command.
Read more about how Postfix can use all kinds of databases (LDAP, SQL, and the like) here:
http://www.postfix.org/DATABASE_README.html
Related
There are plenty of Modules in the Config:: Namespace on CPAN, but they are all limited in ond way or another.
I'm currently using Config::Std, which is fine most of the time, however it makes certain things difficult:
more than two levels of nested directives
handling of multiple values per key
conf.d directories, i.e. multiple config files which are merged into one big config hash
Config::Std generates a blessed hashref after parsing the config, so all my applications are coded to use a hashref for configuration. I'd prefer not having to change this.
What I am looking for is a universal, lightweight Config Module that produces a hashref.
My Question is: Which Config Modules should I consider for replacing Config::Std?
Config::Any (for loading several files and flattening to a hash) and its Config::General backend (for arbitrarily nested configuration items and multiple values per key à la Apache httpd)
You didn't state where your data is coming from. Are you reading in a configuration file and running into the limit of the configuration file itself?
Config::Std is a great module. However, it was meant to read and write Windows Config/INI files, and Windows Config/INI files are very flat and simple formats. Thus, I wouldn't expect Config::Std to do much more.
If you're using Windows Config/INI files right now, but may need to read more complex data structures in the future, Config::Any is a good way to go. It'll handle Windows Config/INI files and using the same programming interface, read and write XML, YAML, and JSON file structures too.
If you're merely trying to keep a complex data structure in your program and don't care about reading and writing configuration files, I would recommend looking at XML::Simple for the very simple reason that it is ...well... simple and can handle all sorts of data structures. Plus, XML::Simple is a very commonly used module, so there's lots of help on the Internet if you have any questions about the module, and it is actively supported.
You could use Config::Any, but I find it more complex to use, and harder to configure. In fact, you have to install XML::Simple (or a similar module) in order to use it. The advantage of Config::Any is that it is a single interface for all sorts of configuration file formats. That way, you don't have to hack through your program if you decide to switch form Windows Config/INI to XML or YAML.
So, if you're working with Windows Config/INI files now, and need a more complex data structure: Look at Config::Any.
If you're merely wanting a simple way to track complex data structures, look at XML::Simple.
YAML will handle that and more.
And here's the website for the protocol.
I want to allow emails like myusername+something#mydomain.com instead of simply myusername#mydomain.com using Zimbra - this is a feature on Gmail.
Does anyone where to begin looking to allow this to work? Postfix?
How to implement this in Zimbra is available on the official Zimbra wiki here:
http://wiki.zimbra.com/wiki/Plus_Addressing
Zimbra stores a lot of Postfix parameters in LDAP so modifying the running Postfix config won't work.
To enable Plus Addressing with Zimbra, use zmprov as follows:
zmprov mcf zimbraMtaRecipientDelimiter +
Note that the delimiter can be a character other than '+'.
To disable Plus Addressing, use zmprov as follows:
zmprov mcf -- -zimbraMtaRecipientDelimiter +
After making changes to enable or disable this feature, it may be required to restart tomcat. Postfix should pick up the changes automatically, though it may take a couple minutes to register.
Yeah, postfix is the right place. Look at recipient_delimiter in the postconf docs:
recipient_delimiter (default: empty)
The separator between user names and address extensions (user+foo). See canonical(5), local(8), relocated(5) and virtual(5) for the effects this has on aliases, canonical, virtual, relocated and on .forward file lookups. Basically, the software tries user+foo and .forward+foo before trying user and .forward.
Example:
recipient_delimiter = +
I need to do mail processing where I manipulate the contents of the mail or invoke a script on the receipt of email, supporting a number of email addresses as the access points. In reading through the MDA agents, procmail appears to be the standard standby, but maildrop has some following too. Wikipedia comments that anyone starting something new should consider maildrop because procmail hasn't been advanced in quite a while.
Are there any solid reasons from features or capabilities that would indicate using one of these over the other?
Here is a summary of what I have read in various places:
Maildrop claims to be a "drop-in replacement" for procmail.
Procmail uses an archaic syntax with several unmemorable single-letter commands. Maildrop uses a more powerful, versatile, and readable pattern-action syntax which bears a strong resemblance to that of awk.
Procmail is more widely used than maildrop. Procmail has more examples available on line.
Procmail reads large messages into memory. Maildrop makes use of pipes and temporary files to avoid overloading RAM. Procmail claims to have a very slight speed advantage.
My suggestion: Read the docs for both, and go with the one whose syntax makes more sense to you.
It is quite difficult to answer. As far as I can see, procmail is very stable and works well.
It is not clear (to me) if maildrop can be integrated so easily in .forward like procmail.
The good things of procmail are:
it is based on pipes, so you can easily add filter using formail+sed+bash
it is easy to build a yes/no filter to use with procmail (i.e. a spam processor)
do most of the things you need
the mailing list is still alive
On the opposite:
procmail syntax for dynamic match is complex (the / stuff) and I have found little example
documentation is scattered on a lot of howto. This url is good
http://pm-doc.sourceforge.net/doc/
but should be edited a bit.
We want to use the same user-id across all our dev tools, but this limitation from subversion is not allowing us to use email addresses as usernames.
Well, since you can create groups consisting of multiple users, and later refer to them by using #<groupname>, I guess having a # in a regular username may be a problem.
This is from the example in the default authz file generated when creating new svn repository:
[groups]
harry_and_sally = harry,sally
[repository:/baz/fuz]
#harry_and_sally = rw
Which gives the users in group harry_and_sally read and write permissions to the repository in /baz/fuz.
It really depends on how you set up Subversion. It's possible that the standard Subversion built-in authentication for svnserve does not allow . and # (I haven't tried). I have set up my Subversion repositories using Apache instead of the built-in svnserve. Under Apache you can use standard Apache access controls like htpasswd files or even integration with LDAP or Microsoft Active Directory. Then you can use e-mail addresses or AD logins for your Subversion users.
Subversion actually uses UTF-8 internally to store all of its data, including the usernames, so there isn't really any restriction on what you can name your users. For example, I just created a commit with the user:
'Й, ק, م, ๗, あ, 叶, 葉, and 말.'
The thing is, other programs may reserve certain characters for special purposes, such as [, =, and # in the svn passwd file. Subversion can handle a wider range of usernames, but that particular file format cannot. If you are finding yourself unable to use certain characters, it is a limitation of some other link in the chain, like Apache or your IDE or your database, or whatever.
That isn't too helpful because you probably can't easily fix whatever is causing this or switch tools, but such is the state of "weird" characters these days.
It does allow "." in username, never tried #.
At my $JOB company e-mail address is the standard user name for Subversion, so it must work.
On my team, however, we insisted on being given our (also company-wide) Windows user names which tend to be no longer than 8 characters. User names like Reallylongfirst.Andlastname#amazing-products.com make for terrible usability in standard GUI log viewers and don't play nicely with svn blame.
The usual way to construct URIs containing a username is
protocol://user#host:port/path. svn uses this too, so the # character is special. I haven't tried but I'm rather confident that you could escape it (like %40) to make it work. However, IMO it's a rather bad idea to use complete email addresses as usernames. If you're inside a company, why can't you use the local part? Everything else will most likely be the same for all users, thus you're only repeating information -- and it won't play nicely with log views.
See also RFC 3986.
I have a framework written in Perl that sets a bunch of environment variables to support interprocess (typically it is sub process) communication. We keep a sets of key/value pairs in XML-ish files. We tried to make the key names camel-case somethingLikeThis. This all works well.
Recently we have had occasion to pass control (chain) processes from Windows to UNIX. When we spit out the %ENV hash to a file from Windows the somethingLikeThis key becomes SOMETHINGLIKETHIS. When the Unix process picks up the file and reloads the environment and looks up the value of $ENV{somethingLikeThis} it does not exist since UNIX is case sensitive (from the Windows side the same code works fine).
We have since gone back and changed all the keys to UPPERCASE and solved the problem, but that was tedious and caused pain to the users. Is there a way to make Perl on Windows preserve the character case of the keys of the environment hash?
I believe that you'll find the Windows environment variables are actually case insensitive, thus the keys are uppercase in order to avoid confusion.
This way Windows scripts which don't have any concept of case sensitivity can use the same variables as everything else.
As far as I remember, using ALL_CAPS for environment variables is the recommended practice in both Windows and *NIX worlds. My guess is Perl is just using some kind of legacy API to access the environment, and thus only retrieves the upper-case-only name for the variable.
In any case, you should never rely on something like that, even more so if you are asking your users to set up the variables, just imagine how much aggravation and confusion a simple misspelt variable would produce! You have to remember that some OSes that will remain nameless have not still learned how to do case sensitive files...
First, to solve your problem, I believe using backticks around set and parsing it yourself will work. On my Windows system, this script worked just fine.
my %env = map {/(.*?)=(.*)/;} `set`;
print join(' ', sort keys %env);
In the camel book, the advice in Chapter 25: Portable Perl, the System Interaction section is "Don't depend on a specific environment variable existing in %ENV, and don't assume that anything in %ENV will be case sensitive or case preserving. Don't assume Unix inheritance semantics for environment variables; on some systems, they may be visible to all other processes."
Jack M.: Agreed, it is not a problem on Windows. If I create an environment variable Foo I can reference it in Perl as $ENV{FOO} or $ENV{fOO} or $ENV{foo}. The problem is: I create it as Foo and dump the entire %ENV to a file and then read in the file from *NX to recreate the Environment hash and use the same script to reference $ENV{Foo}, that hash value does not exist (the $ENV{FOO} does exist).
We had adopted the all UPPERCASE workaround that davidg suggested. I was just wondering if there was ANY way to "preserve case" when writing out the keys to the %ENV hash from Perl on Windows.
To the best of my knowledge, there is not. It seems that you may be better off using another hash instead of %ENV. If you are calling many outside modules and want to track the same variables across them, a Factory pattern may work so that you're not breaking DRY, and are able to use a case-sensitive hash across multiple modules. The only trick would then be to keep these variables updated across all objects from the Factory, but I'm sure you can work that out.