Howto schedule 'mail configuration file' weekly?

Unanswered Question
Apr 10th, 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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
steven_geerts Fri, 04/11/2008 - 23:18

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!


# 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=[email protected]


# Ironport device 1

ssh $[email protected] mailconfig $MAILTO n

# Ironport device 2

ssh $[email protected] mailconfig $MAILTO n

Pat_ironport Sat, 04/12/2008 - 11:45

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

steven_geerts Sat, 04/12/2008 - 14:10

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 Mon, 04/14/2008 - 12:19

It works!

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

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 Separate multiple mail-addresses with commas.

SET [email protected]
SET LOGONusr=IronPortLoginUserName
SET IronPort1=
SET IronPort2=

@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 Tue, 04/15/2008 - 14:40

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.


staylor_ironport Wed, 04/16/2008 - 10:14

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


Pat_ironport Wed, 04/16/2008 - 10:41

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 Wed, 04/16/2008 - 11:49

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 Wed, 04/16/2008 - 16:17

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 Wed, 04/16/2008 - 16:21

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 Wed, 04/16/2008 - 16:37

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 Wed, 04/16/2008 - 16:44

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 Wed, 04/16/2008 - 16:57

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.


This Discussion