Skip to content
Mar 18 / Greg

Mikrotik Change Log 3.22

Here’s the log.

3.21

They added a TFTP server, that’s interesting. They still don’t have the ability to TFTP from the mikrotik to another server, or so it appears. There is still no really functional way for the mikrotik to send his backups to an FTP or TFTP server.

Looks like they back ported their MetaRouter to the rb4XX platform.

3.22

They added some features for the new RB450G. Still waiting for them to send me a copy to test with πŸ˜‰

It appears they added quite a few updates to their MPLS/VPLS engine.

Nothing ground breaking, but interesting.

8 Comments

leave a comment
  1. Jacob Bertling / Mar 20 2009

    The TFTP thing is kind of a big deal isn’t it if you can’t backup your devices and import/export them as needed. Dp you have a work around for this?

  2. Greg / Mar 20 2009

    Indeed good sir, I do. I allow FTP from a specific host. I then run a script on the mikrotik daily that creates a backup file. My FTP host connects everyday and copies this backup off. I would rather the mikrotiks just send their backups, but one can’t have everything.

  3. Rob / Apr 24 2009

    Greg :
    Indeed good sir, I do. I allow FTP from a specific host. I then run a script on the mikrotik daily that creates a backup file. My FTP host connects everyday and copies this backup off. I would rather the mikrotiks just send their backups, but one can’t have everything.

    Is there a reason you don’t just email the backups? This script can be scheduled as often as you like to make a backup file and email it.

    / system script
    add name=”backup” source=”:log info “Starting Backup…”\n \
    /export file=[/system identity get name]\n \
    :delay 20\n /tool e-mail send [email protected] \
    subject=([/system identity get name] . ” \
    Config Backup”) [email protected] \
    file=([/system identity get name] . “.rsc”) \
    server=X.X.X.X \n:log info “Finished Backup!”” \
    policy=ftp,reboot,read,write,policy,test

  4. Greg / Apr 25 2009

    Rob,

    That’s a good point. I keep all of our backups together, so if I did email, I would have to configure a separate email account. I would then have a script that would pop the email account and store the backups to our server.

    I use Cobian for pulling the backups which is great! All I have to do it put in the IP, user/password and it will connect on schedule and pull all files, save for the ones I exclude. It then compresses all of my backed up files.

    Greg

  5. Rob / Apr 25 2009

    Greg,

    If your backups are centrally stored on a machine you could mount as a share on your mail server, I have a procmail recipe and perl script that you might be interested in then. It could probably done entirely with procmail modules from procmail-lib but perl MIME tools and MIME::Parser are what I found originally. If it sounds interesting, I can expand on it more. If not, cobian is great for backups. Been using it for awhile as well. πŸ™‚

    Regards,
    Rob

  6. Greg / Apr 25 2009

    Rob,

    That sounds pretty clean, but I try and keep most of my processes as easily reproducible as possible. Cobian is easy for just about anyone to manage and diagnose/debug. If I roll out Cobian backing up someone’s MTK network, I can hand over the keys without having to worry if they can maintain it.

    Having said that, if you already have the scripts, it would be pretty cool to check them out; sounds like a nice implementation! Quite clever πŸ˜‰

    Greg

  7. Rob / Apr 25 2009

    Greg,

    I don’t know how “user friendly” it would be for someone that wasn’t at least marginally familiar with *nix and sendmail. I haven’t tried it, but the procmail recipe could probably be setup in a global /etc/procmailrc file to redirect all mail to any specific alias you use for your backups and then all that would have to be done is map that alias to a user in /etc/aliases. The global procmailrc would make it more flexible than how I’m doing it now. Other than that, it’s just editing email address in the MT script and the parser script. For that matter, the parser email “notification” isn’t absolutely necessary so you could leave the email out of it entirely and all that would be needed is to setup an alias, send email to that alias from the MT script and set the location to save the attachments in the parser. You’d be “blind” to any messages processed by the procmail recipe though. The NFS share puts it a bit more complex but if the mail server itself were the storage area, it wouldn’t be terribly complex……maybe. :-/ A little more fear factor than cobian and not near as simple for sure but for the networks I manage, it’s been handy. πŸ˜‰

    Rob
    Rob

  8. Greg / Apr 25 2009

    Rob,

    I smell what the rock is cooking, hopefully we will see the scripts soon.

    Greg

Leave a Comment

 

*