Recently had a DC (we'll call it DC1) acting very strangely. There were some errors in the event logs: -------------------------- EventID 1058, The system cannot find the path specified. (then lists a GPO GUID path in SYSVOL) -------------------------- Rebooting would just give me the error again. Tried gpupdate and got this: -------------------------- C:\>gpupdate Updating Policy... User policy could not be updated successfully. The following errors were encount ered: The processing of Group Policy failed. Windows attempted to read the file \\domain.local\SysVol\domain.local\Policies\{9EA16EAF-3A76-4972-88CE-1BA2435CAE8 E}\gpt.ini from a domain controller and was not successful. Group Policy setting s may not be applied until this event is resolved. This issue may be transient a nd could be caused by one or more of the following: a) Name Resolution/Network Connectivity to the current domain controller. b) File Replication Service Latency (a file created on another domain cont...
Fun time figuring this out, I was being bad and not documenting, but here's what I recall: Kept getting 'access denied by server while mounting' errors when using this command: mount -t nfs 10.0.0.14:/volume1/mysql_backup /srv/backup Checked and re-checked the Synology settings to no avail. Thought it was something to do with root squash - was not. Correct settings should be correct IP address, RW, No Mapping, Enable Async SSH'd in to the Synology and after some messing about with /etc/exports, I set up tail -f /var/log/messages Took me a while to notice it, but the IP it was registering was the Astaro gateway IP - the Synology and my PC are on different subnets! Set the NFS rule to '*' and started working immediately. Firewalls make it easy to overlook simple things. I imagine there is some sort of fancy NAT rule for the NFS traffic that would allow specific IPs, but seeing as how I'm technically behind two firewalls and this is a lab, the allow ...
It's pretty simple for the Linux gurus I'm sure...but I ran into the following scenario with one of my clients. Longtime Linux admin leaves - he built all the systems - and a temp admin takes over (part of a takeover). New management decrees security policies, so he resets all of the old ssh account passwords - the changes are not documented. The takeover falls apart, the temp admin is no longer an employee, and control is handed back to the original company. They are left with no admin, and no passwords. The original admin did a great (maybe slightly paranoid) job of setting up and hardening the servers, so of course root has no ssh. This can be overcome by logging on to the console, no problem. One of the other projects the original admin set up was a couple of KVM clusters - they worked great, but one cluster had weird issues (probably hardware/networking, but the original admin left before it could be resolved), and since the temp Linux admin couldn't f...
Comments
Post a Comment