Koozali.org: home of the SME Server
Obsolete Releases => SME Server 8.x => Topic started by: newburns on June 03, 2012, 07:55:20 PM
-
I had a domain server in SME8 beta 7. I did a full restore onto a clean installation of SME 8. No one is able to login.
Windows says the domain and workstation trust relationship has issues. Also, I can't access any files or email because no logins work through windows explorer or webmail. I am able to ssh into the server with putty and WinSCP.
I am guessing there may be a folder that holds permissions that is not being read properly.
Also, I cannot change passwords for users. When I attempt to change the password, it goes to a blank screen. Any ideas?
-
newburns
How did you do the backup and restore, ie default e-smith backup in server manager and restore or ????
-
I installed SME 8 onto a 2tb RAID 5 setup (6 drives). From there, I went to server-manager and changed the settings for remote-access, workgroups, clamav.
Then I went to my AFFA backup and did a full restore once I deleted the key on the AFFA machine, and sent the new key to my new gateway server: 10.1.12.1:255.255.252.0
Now all of the content and users are visible in server-manager and WinSCP, however, all PC connected to the domain have trust relationship issues. And when I log on locally, I am not able to view any folders through the Windows Explorer.
The password fails, even for admin. When I know Admin is correct because of SSH connection.
Update::: I created a new user named "tester". Those credentials work! What about the others. Is there some place I can look specifically? logs?
Update::: The newly created user cannot login to domain. There must be an issue with the username I registered with when initially setting up the domain. One of the Domain Admin users.
Update::: The newly created user is the only user listed in "Quotas" account
Edit::: I failed to mention that the AFFA backup system is a SME 7 machine, NOT an SME 8 machine.
-
http://bugs.contribs.org/show_bug.cgi?id=4527
This closely resembles my issue, however, there was no resolution. All the instructions yield the same results as the other person who had this issue.
-
It seems that I may have misread something, or assumed too much. I am now under the impression that I do not have to enable ssh in the server-manager in order to restore from an AFFA machine.
It will authenticate against keys instead. So I am thinking that a fresh install, without any logging in or modifications, and immediately do a restore for the system. Does that sound about right>?
I hate to keep doing fresh installs as 12TB is a lot to format (Roughly 4 hrs.).
Is there any other answers or logs that I can view?
I have so far:
Jun 3 11:00:43 mtrose esmith::event[12322]: expanding /var/qmail/control/badrcptto
Jun 3 11:00:43 mtrose esmith::event[12322]: generic_template_expand=action|Event|group-modify|Action|generic_template_expand|Start|1338739243 538152|End|1338739243 678738|Elapsed|0.140586
Jun 3 11:00:43 mtrose esmith::event[12322]: Running event handler: /etc/e-smith/events/group-modify/S15group-modify-unix
Jun 3 11:00:43 mtrose esmith::event[12322]: usermod: user office does not exist
Jun 3 11:00:43 mtrose esmith::event[12322]: Failed to modify (unix) group description for office.
Jun 3 11:00:43 mtrose esmith::event[12322]: CPU: ldapOperation: ldap_bind_s: Can't contact LDAP server
Jun 3 11:00:43 mtrose esmith::event[12322]: The LDAP server specified at localhost could not be contacted.
Jun 3 11:00:43 mtrose esmith::event[12322]: Your LDAP server may be down or incorrectly specified.
Jun 3 11:00:43 mtrose esmith::event[12322]: Failed to modify (ldap) group description for office.
Jun 3 11:00:43 mtrose esmith::event[12322]: CPU: ldapOperation: ldap_bind_s: Can't contact LDAP server
Jun 3 11:00:43 mtrose esmith::event[12322]: The LDAP server specified at localhost could not be contacted.
Jun 3 11:00:43 mtrose esmith::event[12322]: Your LDAP server may be down or incorrectly specified.
Jun 3 11:00:43 mtrose esmith::event[12322]: Failed to modify (ldap) group description/email for office.
Jun 3 11:00:43 mtrose esmith::event[12322]: Use of uninitialized value in split at /etc/e-smith/events/group-modify/S15group-modify-unix line 99.
Jun 3 11:00:43 mtrose esmith::event[12322]: Failed to get supplementary group list for aburns.
Jun 3 11:00:43 mtrose esmith::event[12322]: S15group-modify-unix=action|Event|group-modify|Action|S15group-modify-unix|Start|1338739243 678971|End|1338739243 766468|Elapsed|0.087497|Status|256
Jun 3 11:00:43 mtrose esmith::event[12322]: Running event handler: /etc/e-smith/events/group-modify/S20qmail-update-group
Jun 3 11:00:43 mtrose esmith::event[12322]: S20qmail-update-group=action|Event|group-modify|Action|S20qmail-update-group|Start|1338739243 766701|End|1338739243 866621|Elapsed|0.09992
Jun 3 11:00:43 mtrose esmith::event[12322]: Running event handler: /etc/e-smith/events/group-modify/S56update-domain-group-maps
Jun 3 11:00:43 mtrose esmith::event[12322]: Can't lookup UNIX group rburns
Jun 3 11:00:43 mtrose esmith::event[12322]: Can't lookup UNIX group jeagleton
Jun 3 11:00:43 mtrose esmith::event[12322]: Can't lookup UNIX group aburns
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group tmetoyer
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group nharris
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group deagleton
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group cdaniels
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group supervisor
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group photogroup
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group webmin
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group cpatterson
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group youthdepartment
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group webdev
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group lbradford
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group reagleton
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group crobinson
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group allinclusive
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group tearls
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group photographer
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group tgreen
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group gjohnson
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group office
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group blogger
Jun 3 11:00:44 mtrose esmith::event[12322]: Can't lookup UNIX group av
Jun 3 11:00:44 mtrose esmith::event[12322]: S56update-domain-group-maps=action|Event|group-modify|Action|S56update-domain-group-maps|Start|1338739243 866853|End|1338739244 153278|Elapsed|0.286425
Jun 3 11:00:44 mtrose esmith::event[12322]: Running event handler: /etc/e-smith/events/actions/adjust-services
Jun 3 11:00:44 mtrose esmith::event[12322]: adjusting supervised smbd (sighup)
Jun 3 11:00:44 mtrose esmith::event[12322]: adjusting supervised smbd (up)
Which is repeated twice after the new user was created.
Also,
:28 mtrose smbd[30682]: [2012/06/03 10:42:28.313533, 0] rpc_server/srv_netlog_nt.c:475(get_md4pw)
Jun 3 10:42:28 mtrose smbd[30682]: get_md4pw: Workstation MTROSEAV$: no account in domain
Jun 3 10:42:28 mtrose smbd[30682]: [2012/06/03 10:42:28.313602, 0] rpc_server/srv_netlog_nt.c:692(_netr_ServerAuthenticate3)
Jun 3 10:42:28 mtrose smbd[30682]: _netr_ServerAuthenticate3: failed to get machine password for account MTROSEAV$: NT_STATUS_ACCESS_DENIED
Jun 3 10:44:46 mtrose /etc/e-smith/web/panels/manager/cgi-bin/useraccounts[32368]: /home/e-smith/db/accounts: OLD admin=system|EmailForward|both|FirstName|Local|ForwardAddress|rburns@mtrosemedia.tk|LastName|Administrator|Lockable|no|PasswordSet|yes|Removable|no|Shell|/sbin/e-smith/console|VPNClientAccess|no
Jun 3 10:44:46 mtrose /etc/e-smith/web/panels/manager/cgi-bin/useraccounts[32368]: /home/e-smith/db/accounts: NEW admin=system|EmailForward|both|FirstName|Local|ForwardAddress|rburns@mtrosemedia.tk|LastName|Administrator|Lockable|no|PasswordSet|yes|Removable|no|Shell|/sbin/e-smith/console|VPNClientAccess|yes
Jun 3 10:4
-
you will need to enable ssh as that is how affa communicates
-
Maybe something went wrong because I set the domain name for controller. Or something crazy.
Whatever the case, I am installing a fresh copy of sme 8 x64, and from there I will ONLY change ssh option. I will use the earliest backup and bring all the data over afterwards.
If that fails to work, I will be forced to recreate all settings/configurations, and use affa to
-
newburns
....I went to server-manager and changed the settings for remote-access, workgroups, clamav
All you need to do is setup basic networking functionality so that your new server is capable of talking to the backup. Do not add users or ibays or anything else.
Then I went to my AFFA backup and did a full restore...
Please elaborate fully on how you did this.
Is this a backup made to a dedicated Affa backup server, is it a backup made using Affa to USB etc ????
What instructions are you following for the backup, and for the restore ?
Please provide URL's to wiki articles or wherever.
What version Affa are you using, ie the sme contrib v2.x or the more recent Sourceforge hosted v3.x
...all PC connected to the domain have trust relationship issues....
This is typically caused by issues with the machine accounts not being correctly restored, these are in the accounts db.
You can review these to see if present in the (restored) accounts db
db accounts show |more
They are something like station7$=machine
So if you know your workstation names you can do
db accounts show station7$
More research is needed to really determine what went wrong, and whether this is a bug or user error.
Is there some place I can look specifically? logs?
The bug report you referred to advises to look in /var/log/messages.*
ie
From comment 3, "Before we go ahead on the rest we will wait until the correct /var/log/messages.* file is attached so we can have a look at see if a restore took place correctly."
Look around the time the restore took place to see if everything (files and folders etc) were restored correctly.
PS Please answer all questions.
-
I didn't create any users or ibays. I turned on ClamAV, set the workgroups and domain controller to what it had been previously, and then setup remote access for SSH authentication.
I had a full dedicated AFFA backup server running locally on SME 7 through the contribs. I did the affa --full-restore jobname archive
Does SME only look to the one DB folder to resolve machine trust relationships? I have started a new clean install of SME 8 x64. This is a full production environment, so the downtime was not acceptable. I am not capable of an AFFA --rise due to the fact that my backup server has 256mb of memory and one NIC.
I went ahead and restablished all the same configurations, users, ibays, and groups. Exactly like the previously faled server. I am using the RDIR of AFFA's directory to export all user's and ibay's data. Is there a way I can export that specific DB folder that way I don't have to establish new trust on every connected workstation (client)?
Also, unless setting the ClamAV or workgroups and Domain Controller would somehow mess it up, I don't believe it was user error. I had a fresh install, a ton of archives, and I even restored an older archive from before I did the bad update that messed up the production server.
-
newburns
...I turned on ClamAV
Not necessary to do, but should not have caused any problem.
...set the workgroups and domain controller to what it had been previously...
Yes you need to set the workgroup up so that the new server and the Affa backup server can communicate.
There was no need to setup the domain controller, although I do not see that this should or would have caused any problem.
Keep in mind that ALL configuration should be restored to the new server when performing the Restore. It will appear to be the old server with all settings, data, users & so on, all intact, assuming the backup is good and the restore has functioned correctly.
Obviously something has gone wrong.
I had a full dedicated AFFA backup server running locally on SME 7 through the contribs. I did
affa --full-restore jobname archive
Using that command (I assume you got it from here)
http://wiki.contribs.org/Affa#Full_restore
seems to imply the restore is made to an existing sme server that is already setup & functioning, and effectively you are overwriting existing data & settings, when you do the restore, which is a slightly different approach to the standard sme way of doing restore to a clean install of sme OS.
As you are restoring to a clean install of sme OS, then perhaps you should be using this Howto
http://wiki.contribs.org/Moving_SME_to_new_Hardware
Does SME only look to the one DB folder to resolve machine trust relationships?
No it uses many db files, including the /etc/passwd to reconstruct the whole server configuration. User configuration data is NOT only in one file.
Refer to the standard backup inclusions file list.
I went ahead and restablished all the same configurations, users, ibays, and groups. Exactly like the previously failed server. I am using the RDIR of AFFA's directory to export all user's and ibay's data. Is there a way I can export that specific DB folder that way I don't have to establish new trust on every connected workstation (client)?
No. For reasons given above. You have to restore everything using the rsync command (which affa does use).
By doing a "partial" manual restore, you are going to have to rejoin all the workstations to the domain, and all the existing user profiles on the windows workstations will be lost or unusable, it becomes a big task to fix up.
...I don't believe it was user error. I had a fresh install, a ton of archives, and I even restored an older archive from before I did the bad update that messed up the production server.
Well that just confirms your procedure is probably incorrect. You used the same process with an earlier backup and that also failed.
I suggest you try the approach mentioned here:
http://wiki.contribs.org/Moving_SME_to_new_Hardware
Just for completeness, it might also be worth just showing us the output of
cat /root/jobname.pl
at least the part towards the start that shows us ALL the db settings,
and
db affa show jobname
so we can confirm everything is really being backed up, and compare the two to see they are the same.
-
newburns
So what is the outcome of this thread ? Did you follow the other Howto for building a new server ? What result ?
-
I didn't have the time to troubleshoot the restore. The server was in full production, so I went with someone else's solution on restoring everything individually.
What I did was install the new SME 8 server, and set it up exactly the same as the failed server (all users, configurations, ibays, no contribs)
Then, from my AFFA box, I export RDIR=/home/e-smith/files/users/"username"/ # this variable is used to shorten the next command line
rsync -av /var/affa/backups/mtrose/daily.0/$RDIR 10.204.48.1:$RDIRfor each user and ibay.
The last thing I had to do, was remove all the client machines from the domain, and add them again.
Nothing was lost, but time, however, the main ibay was up and running in 30 minutes, which is the center of production. The rest of the files were frivolous, so I had time to restore them.
Just a note though after the first restore attempt:
all the file permissions were numbers, and not user names or group names. This was odd.
Also, you asked for this so here it is
# EDIT THIS:
my %job=(
'remoteHostName'=>'10.1.12.1', # FQHN or IP address
'TimeSchedule'=>'1100', # HHMM,HHMM,...
'Description'=>'MtRose Server', # text string.
'scheduledKeep'=>1, # integer >= 1
'dailyKeep'=>7, # integer >= 0
'weeklyKeep'=>4,# integer >= 0
'monthlyKeep'=>12,# integer >= 0
'yearlyKeep'=>2,# integer >= 0
'SMEServer'=>'yes', # yes | no
'Include[0]'=>'', # additional files or directories to include
#'Include[1]'=>'/rosemedia',
#'Include[2]'=>'',
'Exclude[0]'=>'', # files or directories to exclude from backup
#'Exclude[1]'=>'',
#'Exclude[2]'=>'',
'RPMCheck'=>'yes', # yes | no
'DiskSpaceWarn'=>'strict', # strict | normal | risky | none
'localNice'=>0, # -19...+19
'remoteNice'=>0, # -19...+19
'Watchdog'=>'yes', # yes | no
'sshPort'=>22, # default ssh port is 22
'ConnectionCheckTimeout'=>300, # seconds
'rsyncTimeout'=>1100, # seconds
'rsyncCompress'=>'yes', # yes | no
'EmailAddresses'=>'admin@mtrosemedia.tk', # name@domain.com,name@domain.com,...
'chattyOnSuccess'=>14, # send N success notifications
'RetryAfter'=>600, # retry after 10 minutes
'RetryAttempts'=>3,# number of retries
'RetryNotification'=>'yes', # notify when retrying
'postJobCommand'=>'', # full path to local program/script
'preJobCommand'=>'', # full path to local program/script
'AutomountDevice'=>'', # Device to auto mount (e.g. USB drive)
'AutomountPoint'=>'', # the mountpoint for AutomountDevice
'AutomountOptions'=>'', # Optionstring passed to mount command e.g. '-t cifs'
'AutoUnmount'=>'yes', # umount if fs was not mounted before Affa ran
'RootDir'=>'/var/affa/backups', # where to save the archives. Don't use /root or /home/e-smith
'SambaShare'=>'yes', # enable Samba access to the archives
'Debug'=>'yes', # yes | no
'status'=>'enabled', # enabled | disabled
'rsync--inplace'=>'no', # yes | no : rsync on source supports '--inplace' option
'rsync--modify-window'=>0, # integer >= 0, timestamp window
);
Something else that was strange, the rpm-missing.txt was empty. I know there are differences because the AFFA box only has AFFA and SME7admin.
I am guessing the AFFA box needs to be 8 as well to properly backup the SME 8 box. I don't know, and I know I did a lot of testing with the previous SME8 Beta7 install, so I was going to do a new SME 8 install on the AFFA box, so I wouldn't have this issue agaiun.
I also kept the hard drive operational from the previous install of SME 8, so if there is something that you would like to see on the previous install, I can load it into a test box and get it back up.
-
newburns
I was advising you to do the restore using this method, which I believe is the correct method to use when using Affa to backup & subsequently restore to new hatdware
http://wiki.contribs.org/Moving_SME_to_new_Hardware
The approach you have finally taken is very wrong & as you see, it only partially restores your server.
I'm sure it would have been quicker for you to do the restore correctly using the appropriate & correct method.
As you are the person who had the difficulties, then you are the one who could try restoring the Affa backup to a clean test machine (new OS from CD) using the above method.
I suspect it will work & you will have proven to yourself that this was a case of user error ie following the wrong restore instructions.
-
I had the same exact problem as this, but when I would do a full restore from a backup the problem gets carried over to the new server. I did a backup from the console and the restore from when the installation asks if you want to restore from a backup. I've used affa in the past, but I haven't tried it yet for this problem because I was thinking it would just carry the problem over again.
-
Billymalin
I had the same exact problem as this
If you have a problem that is so serious the users cannot login after restoring from backup, and from what you indicate this is with the default backup system, then you should lodge a bug report immediately so the problem can be identified and fixed for all users.
There is virtually no benefit to anyone from you posting these comments here.