Koozali.org formerly Contribs.org

Standby machine for disaster recovery restore ?

Re: Standby machine for disaster recovery restore ?
« Reply #15 on: November 30, 2018, 09:59:11 AM »
the backup server can even be at a remote location for added security.
If the backup server is local (on LAN) no problems.

Good point. I can pop it in a different building which should add a little more security but that's on the LAN should should be OK speed wise.

Quote
One word of warning/catch22 issue, is that if your sme server acts as gateway, & it goes down/fails, then you may not have remote access via ssh or whatever to do rising etc from a remote location.

It's not the gateway but your comment is a good reminder regarding testing the remote access element.

Any thoughts on the missing packages report ?

Online ReetP

  • *
  • 1,684
Re: Standby machine for disaster recovery restore ?
« Reply #16 on: November 30, 2018, 11:51:26 AM »
Any thoughts on the missing packages report ?

Install them on the affa box. They should sit there quietly doing not a lot until required.

Alternatively you need to install them when you do a rise.
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Re: Standby machine for disaster recovery restore ?
« Reply #17 on: November 30, 2018, 12:08:58 PM »
Install them on the affa box. They should sit there quietly doing not a lot until required.

Alternatively you need to install them when you do a rise.

It turns out that in my notes, I missed that I'd installed another contrib (IMAPsync) and that I think accounts for the missing elements.

I see I have RPMCheck=yes in the config file so is it reasonable to think that it will trigger an email on the next backup (it didn't this morning) or is it a case of stopping and starting the job again ?
« Last Edit: November 30, 2018, 12:51:30 PM by david000 »

Re: Standby machine for disaster recovery restore ?
« Reply #18 on: November 30, 2018, 04:46:57 PM »
Where I am struggling is to get the email alerts delivered onto the production mail server.

The 
Code: [Select]
affa --mailtest backup-smeserver works fine pretty much whatever settings I'm using, however when I trigger
Code: [Select]
affa --send-status

the emails are bouncing.

Code: [Select]
<info@mycompany.co.uk>:
Connected to IP HERE  but sender was rejected.
Remote host said: 550 <root@backup.local> sender rejected - invalid domain (no MX or A record)

I've spent the afternoon trying an assortment of variations on the email set up on the backup server but without much success.   I've tried using the local address for one of the accounts on the production server but not having much luck.  I'd have thought it possible to email the the production server without going out to the ISP ? 




Online ReetP

  • *
  • 1,684
Re: Standby machine for disaster recovery restore ?
« Reply #19 on: November 30, 2018, 05:11:46 PM »
You have given affa a fake domain so the mails will get rejected.

You need to whitelist the IP address in your main server or use some other method to convince your main server to receive mail from the affa box.
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Re: Standby machine for disaster recovery restore ?
« Reply #20 on: December 03, 2018, 03:39:51 PM »
You have given affa a fake domain so the mails will get rejected.

You need to whitelist the IP address in your main server or use some other method to convince your main server to receive mail from the affa box.

I've just realised after 2 days of phaffing that the blindingly obvious solution is to have the production server simply collect mail from the admin mail box of the back-up server...    :lol:
« Last Edit: December 03, 2018, 03:49:43 PM by david000 »

Online ReetP

  • *
  • 1,684
Re: Standby machine for disaster recovery restore ?
« Reply #21 on: December 03, 2018, 06:15:41 PM »
LOL. The simplest ones are the best :-)
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Re: Standby machine for disaster recovery restore ?
« Reply #22 on: December 06, 2018, 12:50:15 PM »
A quick question on Contribs and RPMs to try and resolve the missing RPMs question.

The missing ones are:

Code: [Select]
libmcrypt-2.5.8-9.el6
php-mcrypt-5.3.3-5.el6
php-pear-Mail-mimeDecode-1.5.5-1.el6

all from the @stephdl repository.   My guess is that this is a hang over from the RoundCube installation. I suspect that my production round cube used the @stephdl where as the affa uses the @smecontribs and the difference stem from there.

My question is, as I've have installed the Roundcube Contrib, will the Rise command use that code,  or is it more complicated than that ?

I've yet to try a test 'Rise', but soon.

Offline mmccarn

  • *
  • 2,337
Re: Standby machine for disaster recovery restore ?
« Reply #23 on: December 06, 2018, 01:23:17 PM »
...
I suspect that my production round cube used the @stephdl where as the affa uses the @smecontribs
...

If true, you can verify that you have the correct versions on the backup server using yum info and comparing the output:
Code: [Select]
yum info libmcrypt php-mcrypt php-pear-Mail-mimeDecode

And you could reinstall the packages on the live server from smecontribs to eliminate the error using:
Code: [Select]
yum --disablerepo=stephdl --enablerepo=smecontribs reinstall libmcrypt php-mcrypt php-pear-Mail-mimeDecode

Re: Standby machine for disaster recovery restore ?
« Reply #24 on: December 06, 2018, 02:24:50 PM »
If true, you can verify that you have the correct versions on the backup server using yum info and comparing the output:
Code: [Select]
yum info libmcrypt php-mcrypt php-pear-Mail-mimeDecode

Thanks - I've done that on both machines. On the production server all 3 are listed Installed but 2 (php-pear-Mail-mimeDecode & libmcrypt) are in Red (which I assume is bad in some way) ?

The Backup server only lists php-mcrypt as "available".    (I'm not 100% sure of the implications for this)

Quote
And you could reinstall the packages on the live server from smecontribs to eliminate the error using:
Code: [Select]
yum --disablerepo=stephdl --enablerepo=smecontribs reinstall libmcrypt php-mcrypt php-pear-Mail-mimeDecode

But does it then follow that I can install the packages on the affa backup using:

Code: [Select]
yum --enablerepo=stephdl install libmcrypt php-mcrypt php-pear-Mail-mimeDecode
Which should align the installs ?



Offline mmccarn

  • *
  • 2,337
Re: Standby machine for disaster recovery restore ?
« Reply #25 on: December 07, 2018, 05:46:14 AM »
I think the red indicates that the package is installed but the source repository is not enabled.

Yes, you could install the contribs from stephdl (if they're still there) on the backup server.

I prefer 'smecontribs' to 'stephdl' for no particular reason.  I have a vague memory of an objective announced when SME 7 came out to make sure that all contribs are available from smecontribs... but that's ~10 years ago...


Online ReetP

  • *
  • 1,684
Re: Standby machine for disaster recovery restore ?
« Reply #26 on: December 07, 2018, 11:02:11 AM »
It is better to use smecontribs over a personal repo as contribs is unlikely to go anywhere any time soon, whereas we have no control over personal repos which could disappear overnight.

You can then log bugs here which should get looked at.

Personally I'd prefer that as many private repos as possible were pulled into smecontribs so users only really had to get them from one place.

It means anyone here with dev access can then maintain them if they need patches - I can't work on a package in someone elses private repo.

Yes, I run my own repo which I did early on as I had no dev access and was not very competent. It was a good place to test and I still run a few personal bits from there that aren't worth importing to Contribs, or I use for testing prior to import to Contribs. Anything I had there that was worthwhile is now in Contribs itself.

I now know if I get run over by a truck tomorrow it will still be there :-)


Note the referred RPMs are available:

libmcrypt php-mcrypt php-pear-Mail-mimeDecode

Installed Packages
Name        : php-mcrypt
Arch        : x86_64
Version     : 5.3.3
Release     : 5.el6
From repo   : smeos


Installed Packages
Name        : libmcrypt
Arch        : x86_64
Version     : 2.5.8
Release     : 9.el6
From repo   : epel

php-pear-Mail-mimeDecode.noarch 0:1.5.5-1.el6
Is in epel
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Re: Standby machine for disaster recovery restore ?
« Reply #27 on: December 07, 2018, 12:26:43 PM »
I'm half minded to uninstall Roundcube from the production box and reinstall from the SME repro and see if that resolves the issue.

Is it reasonable to think that uninstall will remove the old RPMs, or leave them just in case there are more dependencies ?

I can't help thinking that the RPMs must be part of a contrib install and if I could ID which one, I'll be sorted.

 

Online ReetP

  • *
  • 1,684
Re: Standby machine for disaster recovery restore ?
« Reply #28 on: December 07, 2018, 12:46:21 PM »
Reading this page there was no reason to have the Stephdl repo, unless you were on v8...

https://wiki.contribs.org/RoundCube

This is all you needed:

Code: [Select]
yum install smeserver-roundcube --enablerepo=smecontribs
Before long you are going to get yourself in a complete muddle.

So before you try ripping things up, go back to the start. What did you do, and why??
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Re: Standby machine for disaster recovery restore ?
« Reply #29 on: December 07, 2018, 03:46:52 PM »
Reading this page there was no reason to have the Stephdl repo, unless you were on v8...

I did make the upgrade from V8 back in the day.

Looking back, based on message dates, the original v8 install was Nov 2013 while it looks like I went over to v9 in May 2015. 

Quote
Before long you are going to get yourself in a complete muddle.  So before you try ripping things up, go back to the start. What did you do, and why??

According to my old notes which have some install info, both Roundcube and Fetchmail were from the stephdl repro, but it's possible there were others.

I think what I'm trying to understand is, is it better to

1. Amend the production box so that it no longer uses the stephdl repro, and hopefully at the same time resolve the missing RPMs. My hope is that by installing say Roundcube and Fetchmail from the sme repro, the process will remove unwanted repro's.

2. Just add the missing RPMs to the affa box and call it quits.

or maybe both ?

My instinct is that getting the production box correct makes sense but I may just end up creating problems for myself  :lol: