Categories
CUPS Model NAS oracle Sharepoint

To domain or not to domain

This past couple of weeks has been interesting. My client that I do a lot of work for has decided that its time they moved to a larger supplier. I’ve been with them for four years now, the last two working from my own office. Its tough being a small business supplying services to a very large one. The difference in my costs to that of their outsourced IT is huge, but would not make a dent on their expense sheet.

This past month I have createing some very shophisticated reports for my client. I have been fiddling with the Oracle model clause because these calculations require inter-row calculations. So to cut down on self-joins I gave it a try. Works a charm on my Oracle 11g server with 4gig ram and oddles of temp and swap space. Did work so well on my client’s 10g server with very resrictive limits. It would run out of memory and also take ages to run, locking up the machine. Luckily I was using my client’s UAT server and not production. I had to revert to using self-joins and a full-outer-join to join the two rows I needed to complete the calculation. Test and test and test again I say.

I’ve managed to finish the domain setup on my Linux machine and now am looking at ways to copy the large amount of data on the current NAS, over to the new NAS. The new NAS has a RAID-5 setup with 900Gig of storage and is properly partitioned to store user files, databases, LDAP database, e-mail etc. I used the Linux LVM to manage this system. Is that a bad move? I could not see an easier way to do it. I suppose I was being lazy. The ability to enlarge the individual logical partitions should come in handy down the road however. Let see.

Before I can move all my Windows users on to the domain, I need a way to preserve their profiles on each machine. I am not using the roaming profile available. I have experience from my client site that these don’t work well as you’l find that machines are setup with different software than your profile and so you usually end up using the same machine each day anyway. I’ve found two links to this.

The second way looks to much simpler. I would appreciate any experience people have had with this.

CUPS might be the standard printing for Linux, and maybe some Unix systems. But I struggle with it. Our Konica-Minolta Bizhub 250, a professional MFP, seems to cause me no end of trouble. The main problem is printing letterhead. The usual way to do this is to put the letterhead into the bypass tray and inform the driver that the first printed page will come from the bypass tray. This avoid the need to open the paper trays and manually insert the letterhead there. This works fine from the Vista machines using the Vista printer drivers. But it completely fails from the XP machines. Cups reports the job as ‘printed’, but the printer never receives the job and nothing is printed. Rather annoying and a common problem with CUPS. It simply does not know if the jobs was actually printed or not.

Its an area that needs serious improvement IMHO.

So when I get all the files from the current NAS and split them and place them on the new NAS and reassign the permissions, which will be LDAP groups and users, the old NAS will become a backup server. I’m only thinking of leaving CUPS, SFTP, NTP and maybe DHCP on the current machine. I’m looking for ideas on backup software to run on this machine. I’ve heard of PCBACKUP, but have yet to install it.

This month I have promised my self that I will install knowledgeroot. And as my contract is running out, I will dedicate myself to learning and playing with sharepoint. I think next time I may describe the folly of uninstalling it, installing SQL Server 2008 and re-installing Sharepoint. I’ll need luck and sweat I think.

Then I can move on to Sharepoint consulting, but its a chicken and egg thing. Would a customer hire me – with 15 years general experience but not certified in Sharepoint – or a certified shop. I think I’ll have to offer some loss-leaders to build up my portfolio. Any tips or leads appreciated.