Recently we've been having trouble with the reliability of our Windows 2000 based print server. Print jobs were becoming stuck in the queue. Typically this had to start happening the week when all the students need to print out their coursework. Murphy's law strikes again. *sigh*
Anyway, I elected to press one of our spare Linux boxes into service as a temporary print server and migrate to it room by room. I chose to use one of our spare AMD64 based standalone server machines (previously used as a temporary server for our VLE).
On the software side of things I used the following:
Ubuntu Linux 6.06 LTS (Server Install)
CUPS
Samba + Winbind
GhostScript ESP
On the printer side of things we mainly have Brother based printers. They generally fall into two categories. Either they support Postscript or they are GDI printers and require a Foomatic driver (the Brother HL1250 driver) to work. There's also a HP 4000 Laserjet and a Lanier photocopier. Both of these print fine with PCL6.
There were a couple of hiccups when configuring the print server. The general procedure is the configure CUPS then try and print from that. Then once CUPS works attempt to hook Samba up to the CUPS back end and print via Samba from a Windows PC. Apart from some stupid mistakes typoing IP addresses configuring CUPs there was no problems getting CUPS to print.
Things got a little more involved on the Samba side of the equation. Firstly I misread the documentation and didn't realise I needed the Postscript driver from Windows. Secondly I had no admin access to the print server from Windows because the default group for 'Administrator' was set to 'Domain Users' rather than 'Domain Admins'. Finally, because Samba was running as a member server on a domain I couldn't log in as 'root', I finally figured out I had to use 'localmachine\root' for my login to work. All of these little hang ups are obvious in hindsight, but they did cause me some serious confusion at the time.
I'm currently in the process of moving the client machines over to the new print server. I've had no complaints of strange or missing printouts so it looks like things are going well.
Friday, February 23, 2007
Tuesday, January 16, 2007
A new job
Well it's certainly been a while since I posted anything here. I kept meaning to but real life comitments and a hectic time at work really didn't leave me with any time to post.
But anyway, all this hard work seems to of paid off. I've been promoted to a new position. Previously I was working in the local primary schools supporting them directly. However I'm now working at the local secondary school instead. This is good for me for several reasons. Firstly, it's full time and therefore more money. Previously I was only working term time. Also it's more interesting work, as it's a bigger and more complex network enviroment than the single server (or peer to peer in some cases!) enviroment in the primary schools. I'm also in charge of the other technicians here, so I get to explore the heady heights of management!
But anyway, all this hard work seems to of paid off. I've been promoted to a new position. Previously I was working in the local primary schools supporting them directly. However I'm now working at the local secondary school instead. This is good for me for several reasons. Firstly, it's full time and therefore more money. Previously I was only working term time. Also it's more interesting work, as it's a bigger and more complex network enviroment than the single server (or peer to peer in some cases!) enviroment in the primary schools. I'm also in charge of the other technicians here, so I get to explore the heady heights of management!
Friday, September 29, 2006
Server Move
Last week I moved our VLE (Moodle) from a P4 Dell server to a brand new AMD64 server. Aside from a few gotchas and stupid mistakes (which I shall elaborate on) it all went pretty well. Quick too. Let me explain how I did it.
Firstly, I had to get the new server setup. This was easy using my Linux distro of choice, Ubuntu. All I had to do was stick the AMD64 server ISO in and choose a 'LAMP' install. This sets up Apache2, PHP5 and MySQL5 for me. The machine had this installed in under 20mins.
Next, I had to do a backup of the old server (just in case!) . I dumped all the databases required. The VLE, room booking system and help desk system (these other systems are internal only, the joys of virtual web hosting). Then I rsynced the web sites (/var/www/sitename/*) and the apache2 configuration (/etc/apache2/*) to our backup machine.
Next I had to transfer the data across to the new server. The database dumps were easy. I just scp'd them across. I also scp'd across the apache2 config and the website. I just had to tarball them beforehand. Once across, I just decompressed them in the correct place.
The databases needed a little more work. I installed PHPMyAdmin (I'm lazy) and re-setup the databases and their users. I then imported the data from the command line using 'mysql' (There's too much data to upload via PHPMyAdmin, more on that later).
At this point I turned the old server off and set the new server to use it's IP addresses (we use IP based virtual hosting, so there are several IP aliases set on the one nic). Everything came back up ok and the VLE worked. Time to go home!
Firstly, I had to get the new server setup. This was easy using my Linux distro of choice, Ubuntu. All I had to do was stick the AMD64 server ISO in and choose a 'LAMP' install. This sets up Apache2, PHP5 and MySQL5 for me. The machine had this installed in under 20mins.
Next, I had to do a backup of the old server (just in case!) . I dumped all the databases required. The VLE, room booking system and help desk system (these other systems are internal only, the joys of virtual web hosting). Then I rsynced the web sites (/var/www/sitename/*) and the apache2 configuration (/etc/apache2/*) to our backup machine.
Next I had to transfer the data across to the new server. The database dumps were easy. I just scp'd them across. I also scp'd across the apache2 config and the website. I just had to tarball them beforehand. Once across, I just decompressed them in the correct place.
The databases needed a little more work. I installed PHPMyAdmin (I'm lazy) and re-setup the databases and their users. I then imported the data from the command line using 'mysql' (There's too much data to upload via PHPMyAdmin, more on that later).
At this point I turned the old server off and set the new server to use it's IP addresses (we use IP based virtual hosting, so there are several IP aliases set on the one nic). Everything came back up ok and the VLE worked. Time to go home!
Tuesday, September 12, 2006
An Apt Quote
My last post on this subject generated quite a lot of controversy. So I thought I'd share a bit of history that turned up during my research into the subject. Here is a famous quote by A. C. Hobbs, an American lock picker who forced lock makers to improve their designs by publicly breaking locks at the Great Exhibition of 1851.
A commercial, and in some respects a social doubt has been started within the last year or two, whether it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and know already much more than we can teach them respecting their several kinds of roguery.
Rogues knew a good deal about lock-picking long before locksmiths discussed it among themselves, as they have lately done. If a lock, let it have been made in whatever country, or by whatever maker, is not so inviolable as it has hitherto been deemed to be, surely it is to the interest of honest persons to know this fact, because the dishonest are tolerably certain to apply the knowledge practically; and the spread of the knowledge is necessary to give fair play to those who might suffer by ignorance.
It cannot be too earnestly urged that an acquaintance with real facts will, in the end, be better for all parties. Some time ago, when the reading public was alarmed at being told how London milk is adulterated, timid persons deprecated the exposure, on the plea that it would give instructions in the art of adulterating milk; a vain fear, milkmen knew all about it before, whether they practiced it or not; and the exposure only taught purchasers the necessity of a little scrutiny and caution, leaving them to obey this necessity or not, as they pleased.
-- From A. C. Hobbs (Charles Tomlinson, ed.), Locks and Safes: The Construction of Locks. Published by Virtue & Co., London, 1853 (revised 1868).
Saturday, September 09, 2006
Friday, September 08, 2006
Security through Obscurity
This is a follow up to my 'The trouble with NAT' post. I thought I should explain the other aspect to the thread that surfaced as it progressed as it touch on some other very interesting (and apparently controversial) points of view. As I previously explained the original poster of the thread had hit a brick wall in attempting to access a website. If you want to know the full details of why and how you really should read my previous blog entry. If not then read on.
After a while a possible solution emerged to the IP ban. Use an anonymous proxy. There is however a catch with that. Most educational institutions use web filtering software to block certain categories of websites. There's the usual obvious stuff like porn, warez, gambling etc. But most also attempt to block sites that have Trojans/viruses and most relevant for our situation sites that allow users to bypass the filtering. The vast majority of these only filter based on the sites domain or the URL.
This is hopelessly inflexible. Your fighting a losing battle trying to keep up with all the new sites going up on a daily basis. No, a much more sensible and proven method is to filter based on the content of the actual web pages. This how your virus scanner and spam filter works after all! To that end I use a web filter called DansGuardian. It does domain, URL and content filtering plus it can scan for viruses.
However it seems quite a few schools are using inferior systems (and paying for them to boot!). This got me into a little trouble and a few flames. When I pointed out that the original poster could setup a simple PHPProxy based system that would solve his problem my post was moderated. Now as far I'm concerned there really isn't any point.
Not withstanding the fact PHPProxy had been mentioned previously to illustrate exactly the problems I've outlined. I feel that the tools themselves are not to blame. There always will be someone out there who wishes to take freely available information and do something harmful or illicit on their work/school/college network. You just have to prepare your systems as secure as possible and have monitoring systems in place to catch them. Assuming you do then hope your AUP is sufficient to deal with them when you catch them.
After a while a possible solution emerged to the IP ban. Use an anonymous proxy. There is however a catch with that. Most educational institutions use web filtering software to block certain categories of websites. There's the usual obvious stuff like porn, warez, gambling etc. But most also attempt to block sites that have Trojans/viruses and most relevant for our situation sites that allow users to bypass the filtering. The vast majority of these only filter based on the sites domain or the URL.
This is hopelessly inflexible. Your fighting a losing battle trying to keep up with all the new sites going up on a daily basis. No, a much more sensible and proven method is to filter based on the content of the actual web pages. This how your virus scanner and spam filter works after all! To that end I use a web filter called DansGuardian. It does domain, URL and content filtering plus it can scan for viruses.
However it seems quite a few schools are using inferior systems (and paying for them to boot!). This got me into a little trouble and a few flames. When I pointed out that the original poster could setup a simple PHPProxy based system that would solve his problem my post was moderated. Now as far I'm concerned there really isn't any point.
Not withstanding the fact PHPProxy had been mentioned previously to illustrate exactly the problems I've outlined. I feel that the tools themselves are not to blame. There always will be someone out there who wishes to take freely available information and do something harmful or illicit on their work/school/college network. You just have to prepare your systems as secure as possible and have monitoring systems in place to catch them. Assuming you do then hope your AUP is sufficient to deal with them when you catch them.
Thursday, September 07, 2006
The trouble with NAT
There was a forum topic earlier this week on Edugeek (a very good site, recommended) concerning a user who was at college and he had lost access to some online forums. This was because his college uses NAT to allow the many PC's on their private LAN to access the Internet simultaneously. The forum admins had banned the IP of the problem user but because all the users at the college appear as coming from one IP the forum admins had effectively banned the entire college from their site. Naturally he had contacted the admins to re-establish access. They apparently declined.
I personally have seen the same problem on Wikipedia. IP bans are quite common for 'anonymous' editors who vandalise and blank pages. In fact I raised this issue not long ago with our LEA because the proxy servers the schools used were blocked from editing. There is little that they can do of course. Happily with Wikipedia it's possible to get round the editing ban by creating a user account. Any edits will then be attributed to the account and not the IP even the IP is blocked from editing.
I suspect NAT will be with us for a long time to come and this is one of many unfortunate side effects. Of course it has it's advantages for sharing the Internet and providing security for machines behind the NAT gateway. But it really isn't the way the Internet is supposed to work. A lot of software (Video conferencing, Instant Messaging, VoIP, P2P apps like Bit torrent for example) assumes end to end compatibility which has to be hacked around to work with NAT.
Roll on IPv6!
I personally have seen the same problem on Wikipedia. IP bans are quite common for 'anonymous' editors who vandalise and blank pages. In fact I raised this issue not long ago with our LEA because the proxy servers the schools used were blocked from editing. There is little that they can do of course. Happily with Wikipedia it's possible to get round the editing ban by creating a user account. Any edits will then be attributed to the account and not the IP even the IP is blocked from editing.
I suspect NAT will be with us for a long time to come and this is one of many unfortunate side effects. Of course it has it's advantages for sharing the Internet and providing security for machines behind the NAT gateway. But it really isn't the way the Internet is supposed to work. A lot of software (Video conferencing, Instant Messaging, VoIP, P2P apps like Bit torrent for example) assumes end to end compatibility which has to be hacked around to work with NAT.
Roll on IPv6!
Subscribe to:
Posts (Atom)