Howto schedule 'mail configuration file' weekly?

Pat_ironport · ‎04-10-2008

It would be great if we could schedule a task sending us the actual configuration file by mail every week. (We know, that we can mail the file manually from 'System Administration', 'Configuration File').

Security is not an issue for us, such a mail doesn't leave the company.

The final goal is an actual backup file on our backup-server.
We have a special mailbox to process such mails and save the attachment(s) to a network drive according to the sender-address.

Is this possible?

steven_geerts · ‎04-11-2008

Yes, this is possible. I have craeted a litte nix shell script that can do the job (i'm not a briliant Unix admin so there might be some enhancements possible, please inform me of these if you are a GURU)

the script is scheduled in the crontab of my Unix management server. The user that owns and executes the crontab has a SSH public key authentication active for connecting to the Ironports.
change the MAILTO variable to your Email address of choise and fill in the hostnames that you can connect to.

Good luck!

Steven

#!/usr/local/bin/bash
# mail the Ironport configuration files to a mailbox.
# user corntab to schedule this script once a week
# make sure the user that owns the crontab can connect
# to the devices with SSH public key authentication
# 19-07-07 Steven Geerts V1.0

MAILTO=your.admin.mailbox@your.domain

LOGONUSR=TheUserIdYouHaveSSHlogonFor

# Ironport device 1

ssh $LOGONUSR@DevicenameOne mailconfig $MAILTO n

# Ironport device 2

ssh $LOGONUSR@DevicenameTwo mailconfig $MAILTO n

Pat_ironport · ‎04-12-2008

Thank you for that script! I will try it next week @ work.
Just one little question: What does 'n' stand for?

steven_geerts · ‎04-12-2008

that's an option of the mailconfig command.

The "n" indicates the passwords of your users are not exported, if you provide a "y" as option the passwordt are noted in the config file

Pat_ironport · ‎04-14-2008

It works!

We are working in a windows environment with this adapted batchfile:

REM
REM Mail the Ironport configuration files to a mailbox. 
REM Use windows tasks to schedule this script once a week 
REM Make sure the user used in tasks can connect to the 
REM devices with SSH public key authentication 
REM
REM Separate multiple mail-addresses with commas.

SET MAILTO=myown.account@company.com
SET LOGONusr=IronPortLoginUserName
SET IronPort1=1.2.3.4
SET IronPort2=1.2.3.5

@ECHO IronPort 4
ssh %LOGONusr%@%IronPort1% mailconfig %MAILTO% y

@ECHO IronPort 5
ssh %LOGONUSR%@%IronPort2% mailconfig %MAILTO% y

We use 'y' (include Passwords) after readring:

Do you want to include passwords? Please be aware that a configuration without passwords will fail when reloaded with loadconfig.

And we are sure enough that this is not a security issue in our environment. :wink:

staylor_ironport · ‎04-15-2008

Please remember that if you are using this backup of the configuration file for disaster recovery that you must NOT mask passwords, otherwise it won't load back on.

Regards

Pat_ironport · ‎04-16-2008

Do you know the command line parameter for 'unmasking'?

staylor_ironport · ‎04-16-2008

All you need to do is to make sure that you DO include passwords when using the mailconfig from the CLI

Regards

Pat_ironport · ‎04-16-2008

Ahh, now I understand. This has nothing to do with the fact that even with the parameter 'y' the password will not be saved in cleartext (unmasked) in the XML.

staylor_ironport · ‎04-16-2008

So from what I know of that script, the "Y" should be the trigger to chose to include passwords, this will enable a loadbale configuration file. Choosing "Y" means that in the configuration file you should have the hashed password using the "md5" algorithm, if you say "N" to including passwords then the configuration will include *******'s instead of the password.

Hope this makes sense, basically "y" can be used for disaster recovery and "n" can't :wink:

Donald Nash · ‎04-16-2008

Now if you guys could just get saveconfig/loadconfig to work properly in a clustered environment, that would be great. Saving the configuration doesn't do much good if you can't load it back in later.

Failing that, I'd be satisfied with a tool that would take the saved configuration file from a cluster and break it out into individual, non-clustered configuration files for each cluster member. That would let me load a standalone ESA with the right configuration and bootstrap a new cluster from it.

staylor_ironport · ‎04-16-2008

Yes totally new forum all together but you are correct, we do have some items roadmapped for upgrades and configuration files, however at the moment you can either save the clustered config and remove any items referencing the cluster, or the easier way is to disconnect a machine from the cluster and then take the config and rejoin afterwards :)

Watch this space as improvements could be on the way, for more information contact your local Product Manager

Donald Nash · ‎04-16-2008

save the clustered config and remove any items referencing the cluster

That would gut our configuration, since everything is configured at the cluster level except for the network and logging. I've never been very averse to editing configuration files manually, and I could probably figure out how to slice-and-dice a cluster config to create a standalone config for one ESA. But clustering significantly increases the complexity of the config file, and I wouldn't necessarily have as much faith in the result as I would like. That's not the state of affairs that you want when doing disaster recovery.

disconnect a machine from the cluster and then take the config and rejoin afterwards

As I recall, you can't just disconnect, you must take an ESA completely out of the cluster. We can't automate that because it would clobber the unique logging configuration that each ESA has (they each do log pushes to different directories).

Watch this space as improvements could be on the way, for more information contact your local Product Manager

I'm glad to hear that this is on the radar.

staylor_ironport · ‎04-16-2008

Yes yet again me typing too quickly misses half of the story out, you are correct but the method that I mentioned is away of getting the configuration of one machine and being able to use it at a later date to place back on one machine, obviously you would need to recreate the cluster all over again.

Donald Nash · ‎04-16-2008

Recreating the cluster doesn't bother me. Editing a cluster config file to produce a standalone config file is what I'm worried about. Like I said, I could probably figure it out, it just wouldn't inspire me with the greatest confidence.