Topic: Last known good config

[janet]

smnirosh

....I am stucked....

First of all your knowledge of sme server seems poor, so do not start doing procedures that you are unsure of or are guessing may have a satisfactory outcome.
LISTEN to the advice that the very knowledgeable people here are giving you, & slowly & completely read everything they have answered to you.

I think you are on the wrong approach trying to backup & do selective restore of files. You are likely to get your server in a much bigger mess & even an inoperative state if you restore files wrongly.
You would need to have a very good knowledge of sme server to know which files to restore to just get configuration information restored. Configuration data is held in numerous files, & some of that information correlates to data in other files, get them wrong, & your server may not work.

Note that you can safely run "Configure this server" anytime.
If you step through all the settings & do not change anything, & the system does a reboot, all your user data in ibays etc & email will still be there, these remain unchanged, even the configuration will remain unchanged, it is just that old configuration setting values will be replaced with the same new values.

As mentioned earlier by Charlie, you can see what changes you may have inadvertantly made, by going through the /var/log/messages log file, & review the configuration commands which will show OLD & NEW configuration entries.
It should be relatively straightforward to indentify any changes you made, if any were made.
If nothing changed, then the OLD & NEW settings will be the same.
Either way a reboot will not harm your server or the data it contains.
At worst you may need to re-run "Configure this server" & correct any incorrect setting, which are mainly relating to network connectivity & basic server settings etc.

If you backed out of the "Configure this server" process, then I would assume you have not changed anything (?)

Trying other procedures such as backup & selective restore will be much more difficult than just running "Configure this server" & making a correction.
Perhaps nothing has changed & there will be no unwanted effects after you reboot.

Please do not complicate your situation by doing other things that are not really warranted.

One thing for sure you should do first, is step through the "Configure this server" screens again, & write down every single setting & the current value displayed. It may take you 15 minutes, but at least you will have a seperate "paper based" record that you can refer to if necessary ie should you need to correct a inadvertantly or wrongly changed setting or two.

If there is a problem after the reboot that you are fearful of doing, then you can ask here for hints or tips regarding the correct setting choices, & advise us what the current settings are based on the written list you made.

THINK FIRST

[CharlieBrady]

At the same time it would be so easy to create a separate db activity log.

Really? Perhaps you should create a NFR in the bug tracker and record your ideas there.

[CharlieBrady]

If nothing changed, then the OLD & NEW settings will be the same.

No, if nothing changed there will be no OLD & NEW records.

[CharlieBrady]

At worst you may need to re-run "Configure this server" & correct any incorrect setting, which are mainly relating to network connectivity & basic server settings etc.

Correct. Janet's advice is sound. That is a much safer way forward than to try to selectively restore files.

[guest22]

As a tip:


you can make a backup of your complete configuration db with the following command:


config show > backup_27aug2015.txt


This will result in a plain text file you can archive off server. Same goes for all other db's

[stephdl]

As a tip:


you can make a backup of your complete configuration db with the following command:


config show > backup_27aug2015.txt


This will result in a plain text file you can archive off server. Same goes for all other db's

this is something that we could have in  a cron each night, keep at least one week of backups. Ideally if we don't use an archive, it will be easier to compare change with a diff.

[janet]

Hi Charlie

No, if nothing changed there will be no OLD & NEW records.

OK then, I am sure you have a better understanding than me but....

As the system is asking that a reboot should be done, then the system at least "thinks" or "believes" that a change has been made, even though OP suggests no changes were made, so is it possible that no change was made by OP but the system still wants to do a reboot, or will a reboot only be requested if at least one change was made to at least one setting, even if changed to something different & then changed back to what it originally was ?
In that scenario will there be OLD & NEW records that are the same ?

[janet]

stephdl & RequestedDeletion

this is something that we could have in  a cron each night, keep at least one week of backups. Ideally if we don't use an archive, it will be easier to compare change with a diff.

Does this really gain anything we do not already have.
The daily backup has the configuration db included, & that can be accessed from the archive if needed, & reviewed in much the same way if you really need to create a txt file ie
cat configuration > backup_28aug2015.txt

I have backups going back a year or more so can access the configuration db file & so on as at any time in the last couple of years, no extra files needed to do that.
This idea still does not answer or provide what smnirosh is originally asking/hinting for, ie the last known good configuration ala Windows style.
For that you would have to create a seperate txt file(s) or archived configuration database file (& anything else needed), every time a configuration change is made, & then incorporate that into some sort of GUI panel or text based graphic menu, quite a lot of work I would think.
I do not recall anyone ever asking for such a thing for over 10 years or more now, so not really a "big demand" request item.

Note that an earlier version of sme server, I think it was v4 & maybe as late as v5 or v6, did have a configuration only backup to floppy disk, so this has been done before.
I recall it was very useful for creating clone copies for test purposes etc, but it was phased out, I think the reason was that the basic data had become too big to fit onto a floppy disk.
So the code would be available from old sme server version archives, & such a backup would be easily saved to a small USB memory stick, similar to the console full backup to attached USB.

I think these discussions only promote the idea of OP (smnirosh) playing around with restoring the configuration db file & so on, whereas I had hoped people here would discourage smnirosh from doing so, & follow the path of doing the reboot & running "Configure this server" again, if needed.
At least Charlie agrees with me on this.

[Stefano]

Note that an earlier version of sme server, I think it was v4 & maybe as late as v5 or v6, did have a configuration only backup to floppy disk, so this has been done before.
I recall it was very useful for creating clone copies for test purposes etc, but it was phased out, I think the reason was that the basic data had become too big to fit onto a floppy disk.
So the code would be available from old sme server version archives, & such a backup would be easily saved to a small USB memory stick, similar to the console full backup to attached USB.

nowadays server can contain terabytes of data.. a restore from a backup can take hours, too many hours.. and if you had a crash and need to be online asap, the only way is to restore configuration, let the server start working (think about email) and then you can restore your data..

in other distros there's such a feature..

[smnirosh]

First of all thanks to u all wasting time on my post.
I am getting near to the anawer if chalie answers the question of janets "OLD & NEW SETTINGS ARE SAME?" . Chalie give a clue. Thanks.

[janet]

smnirosh

An answer from Charlie to my question, is really just a theoretical answer, & does not greatly help or change your situation.

I am getting near to the anawer if chalie answers the question of janets "OLD & NEW SETTINGS ARE SAME?" . Chalie give a clue.

No one can tell you what has happened to your server except you.

You need to look at the messages log file, it is in /var/log/messages
or you can view the messages log files in the server manager View log files panel.

I suggest you immediately review the messages log file, going back to the date & time in question when you ran the "Configure this server" routine.
Copy all the entries made around that time & review them for changes (or for no changes at all) ie look at OLD & NEW settings.
You can post all the entries here & we can review them.

You have to provide us the answer, & the answer is on your server in the messages log file.
That will reveal what changes, if any, were made.

Get on with it, either reboot & hope for the best, or review the log files for changes, & react accordingly.
At least you will know what changes were made & can manually change them back by running "Configure this server" again.
It is safe to do.

[Frank VB]

smnirosh

Let's get you on the right track with a practical example. I did a little experiment on my test server to show what you should be looking for in the log files. I logged on to the console of my test server and changed one setting: the IP address of the server. Then I rebooted (as suggested in the console menu).

Now let's go and find the old setting and the new setting in the messages log.

Log in as root on your server and go to the /var/log directory:

Code: [Select]

cd /var/log
Now, dump the complete messages log on the screen but only get the lines containing the string "bootstrap-console-save/S00initialize":

Code: [Select]

cat messages | grep 'bootstrap-console-save/S00initialize'
In the case you've reconfigured and rebooted your server more than once you will get a lot of lines. But if you know on which day you changed the settings (e.g. 28th Aug.) you can filter those lines from the messages log by using:

Code: [Select]

cat messages | grep 'Aug 28' | grep 'bootstrap-console-save/S00initialize'
In our example, the output is not overwhelming:

Code: [Select]

Aug 28 11:54:24 joomla0 esmith::event[1747]: Running event handler: /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases
Aug 28 11:54:27 joomla0 /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases[1748]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|192.168.1.255|Configuration|static|Driver|e100|EthtoolOpts|wol -g|HWAddress|00:0f:fe:3c:e0:2b|IPAddress|192.168.1.10|NICBonding|disabled|NICBondingOptions|miimon=200 mode=active-backup|Name|eth0|Netmask|255.255.255.0|Network|192.168.1.0
Aug 28 11:54:27 joomla0 /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases[1748]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|192.168.1.255|Configuration|static|Driver|e100|EthtoolOpts|wol -g|HWAddress|00:0f:fe:3c:e0:2b|IPAddress|192.168.1.11|NICBonding|disabled|NICBondingOptions|miimon=200 mode=active-backup|Name|eth0|Netmask|255.255.255.0|Network|192.168.1.0
First, look at the date and time! You know when you first started changing the settings, I hope. We have 3 entries (they all have practically the same time stamp). Look at the second entry:

Code: [Select]

Aug 28 11:54:27 joomla0 /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases[1748]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|192.168.1.255|Configuration|static|Driver|e100|EthtoolOpts|wol -g|HWAddress|00:0f:fe:3c:e0:2b|IPAddress|192.168.1.10|NICBonding|disabled|NICBondingOptions|miimon=200 mode=active-backup|Name|eth0|Netmask|255.255.255.0|Network|192.168.1.0
Scroll to the right. Did you notice the word "OLD"? This line contains the old settings, i.e. the settings before you changed them in the console and rebooted. The settings are stored mostly as "parameter|value" pairs. Now, take a look at the "IPAddress" parameter and the IP-address value "192.168.1.10":

Code: [Select]

IPAddress|192.168.1.10
This was the old IP-address of the server.

Now, look at the third line:

Code: [Select]

Aug 28 11:54:27 joomla0 /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases[1748]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|192.168.1.255|Configuration|static|Driver|e100|EthtoolOpts|wol -g|HWAddress|00:0f:fe:3c:e0:2b|IPAddress|192.168.1.11|NICBonding|disabled|NICBondingOptions|miimon=200 mode=active-backup|Name|eth0|Netmask|255.255.255.0|Network|192.168.1.0
Again, scroll right to see the word "NEW". Find the "IPAddress" parameter. Immediately, next to it you'll see the IP address "192.168.1.11".

So this tells us that the old IP-address set in the console was 192.168.1.10 and then it was changed in the console to 192.168.1.11.

This is a simple example. What you'll have to do is compare every parameter|value in the "new" line with the "old" line and find out what you did change, write those down and then carefully enter them in the console. Reboot your server and hopefully everything will be OK.

HTH

PS: a good system administrator keeps a log of *everything* he changes on his/her server(s).

[CharlieBrady]

As the system is asking that a reboot should be done, then the system at least "thinks" or "believes" that a change has been made, even though OP suggests no changes were made, so is it possible that no change was made by OP but the system still wants to do a reboot, or will a reboot only be requested if at least one change was made to at least one setting, even if changed to something different & then changed back to what it originally was ?

If something was changed, and then changed back, then there will be two sets of NEW/OLD recorded in the messages log file, and the console will want to reboot the server, even though there are no overall changes in the configuration.

It's possible that there are problems in the code where it is making such change then re-change steps, so that it inappropriate reports changes and asks for a reboot. Reviewing the messages file is the only way to detect if that is what has happened.

In that scenario will there be OLD & NEW records that are the same ?

There will never be corresponding OLD & NEW which are the same. When a change is made and then reversed, there will be OLD/NEW/OLD/NEW, with the first OLD matching the second NEW.

Get on with it, either reboot & hope for the best, or review the log files for changes, & react accordingly.

Very good advice.

[CharlieBrady]

Now let's go and find the old setting and the new setting in the messages log.

Frank, good approach to go through an example, but you need to go earlier in the messages log to find the changes you made in the console. You might need to look in an earlier messages.nnnnn file. Your analysis is looking at what took place after the system reboot. What you have showed is where the LocalIP setting is copied into the IPAddress property of the InternalInterface record. You need to find where the value was changed in the console, as that is what OP will need to find. Earlier you will see where the LocalIP value was changed from the console.

[Unfortunately you picked one of the very few items which is duplicated in the configuration database.]

[Frank VB]

Frank, good approach to go through an example, but you need to go earlier in the messages log to find the changes you made in the console. You might need to look in an earlier messages.nnnnn file. Your analysis is looking at what took place after the system reboot. What you have showed is where the LocalIP setting is copied into the IPAddress property of the InternalInterface record. You need to find where the value was changed in the console, as that is what OP will need to find. Earlier you will see where the LocalIP value was changed from the console.

Point taken, Charlie. I looked again at my messages log files. A little bit earlier I saw these lines:

Code: [Select]

Aug 28 11:52:41 joomla0 /sbin/e-smith/console[3369]: /home/e-smith/db/configuration: OLD UnsavedChanges=no
Aug 28 11:52:41 joomla0 /sbin/e-smith/console[3369]: /home/e-smith/db/configuration: NEW UnsavedChanges=yes
Aug 28 11:52:41 joomla0 /sbin/e-smith/console[3369]: /home/e-smith/db/configuration: OLD LocalIP=192.168.1.10
Aug 28 11:52:41 joomla0 /sbin/e-smith/console[3369]: /home/e-smith/db/configuration: NEW LocalIP=192.168.1.11

Should he be looking for those pointers? Of course, my example was only for a change in IP address. If OP also changed other settings (Server/Gateway mode, ...) that's probably a more complicated story. But let's hope he learns from this.