So having moved from a piecemeal Ubuntu server solution to Zentyal for my home server, the one last thing I'm having trouble setting up is printer sharing. There seems to be three ways to do it; via the printers app, on the Zentyal console or via the CUPS webpage. It turns out the correct way to setup a printer for Zentyal to share is via the CUPS route.
This was all well and good, and I eventually worked out how to setup my printer and share it. But I made one schoolboy error and ticked the Kerberos authentication box. When I tried to reconnect to the CUPS webpage all I got was an unauthorised access page and no login box. There was no way for me to get back into the web config to fix the problem. This seems to be a bit of bug that needs addressing but I suppose common sense prevails and not ticking boxes without knowing the outcome is probably the best way forward. We can't wrap everyone in bubblewrap and even us IT guys need to exercise caution at times!
Fortunately it turns out that if you find yourself in this situation, all you need to do is log onto the server and replace the /etc/cups/cupsd.conf file with the default file. If you can't find the default file (like me) then just copy the text from another file or the internet and paste it into your cupsd.conf file.
To save you lots of further hunting, the original cupsd.conf file content can be found on answers.launchpad.net courtesy of the user actionparsnip. Thanks fella!
Thursday 25 September 2014
Monday 22 September 2014
XRDP and Zentyal Server
Due to a... ahem... user error recently, I've found myself in a position to rebuild by home server. So I decided to go back and give Zentyal a try as it looks like its improved a lot since I last tried it out. Configuration of the server so far has been a breeze and the amount of documentation provided by the team and community at Zentyal is fantastic.
However I wanted to do one thing that was documented and setup remote access to the server. I know that pretty much everything can be done through a browser, but my home server isn't attached to a keyboard or monitor, so I like to have a way of getting into the server to troubleshoot. My software of choice is XRDP as I've used it all before and it works like a charm.
Unfortunately, this time it didn't quite go as smoothly as previous experiences. I'd managed to setup the port access on the Zentyal firewall and my RDP client could remote to the correct ports, but internal routing from the RDP service to the internal VNC server wasn't working. I kept getting this error:
connecting to sesman ip 127.0.0.1 port 3350
sesman connect ok
sending login info to session manager, please wait...
xrdp_mm_process_login_response: login successful for display
started connecting
connecting to 127.0.0.1 5910
error - problem connecting
After much trial and error, and many Google searches I discovered a post on the Ubuntu Forums from spider-byte describing exactly the same problem. His solution was to reinstall both XRDP and tightvncserver separately through synaptic. As a test I reinstalled tightvncserver with apt-get and voila, problem solved. I'm not sure if this is a common occurrence or just my config gone wrong, but I thought I'd share my solution and my thanks to spider-byte.
However I wanted to do one thing that was documented and setup remote access to the server. I know that pretty much everything can be done through a browser, but my home server isn't attached to a keyboard or monitor, so I like to have a way of getting into the server to troubleshoot. My software of choice is XRDP as I've used it all before and it works like a charm.
Unfortunately, this time it didn't quite go as smoothly as previous experiences. I'd managed to setup the port access on the Zentyal firewall and my RDP client could remote to the correct ports, but internal routing from the RDP service to the internal VNC server wasn't working. I kept getting this error:
connecting to sesman ip 127.0.0.1 port 3350
sesman connect ok
sending login info to session manager, please wait...
xrdp_mm_process_login_response: login successful for display
started connecting
connecting to 127.0.0.1 5910
error - problem connecting
After much trial and error, and many Google searches I discovered a post on the Ubuntu Forums from spider-byte describing exactly the same problem. His solution was to reinstall both XRDP and tightvncserver separately through synaptic. As a test I reinstalled tightvncserver with apt-get and voila, problem solved. I'm not sure if this is a common occurrence or just my config gone wrong, but I thought I'd share my solution and my thanks to spider-byte.
Friday 21 March 2014
Mac user can't login to Windows domain
Had a quick question this afternoon from someone who had setup a Mac in a Windows domain environment. After setting up and joining the domain they had no problem logging onto the Mac with their Windows username and password. However, seemingly at random they were suddenly unable to login anymore.
It turned out to be quite a simple solution to the problem; the clock on the Mac was out of sync with the Windows domain controller. The Mac was running six minutes faster than it's Windows colleagues. Once the time was corrected the user was able to login to the Mac again with their Windows login.
It turned out to be quite a simple solution to the problem; the clock on the Mac was out of sync with the Windows domain controller. The Mac was running six minutes faster than it's Windows colleagues. Once the time was corrected the user was able to login to the Mac again with their Windows login.
Outlook 2010 cannot verify licence
I was reimaging a faulty computer today with a working Ghost image I had made some time back when I encountered an error opening Word. Every time I tried to open any of the Microsoft Office 2010 applications I got this error message:
"Microsoft Office cannot verify the license for this product. You should repair the Office program by using Control Panel."
After a bit of searching I discovered the answer was quite a simple one. The problem was that I had created the image some time back and the activation grace period had expired. In order to get Office to activate properly I needed to rearm the activation period.
To do this you need to open a command prompt with elevated administrator rights and type in the following command:
C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe
This resets the 30 day grace period and you are once again able to open and activate Microsoft Office.
"Microsoft Office cannot verify the license for this product. You should repair the Office program by using Control Panel."
After a bit of searching I discovered the answer was quite a simple one. The problem was that I had created the image some time back and the activation grace period had expired. In order to get Office to activate properly I needed to rearm the activation period.
To do this you need to open a command prompt with elevated administrator rights and type in the following command:
C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe
This resets the 30 day grace period and you are once again able to open and activate Microsoft Office.
Subscribe to:
Posts (Atom)