Another in the series of this is harder than it should be
This should be a simple enough job - after all 'it works on ubuntu out of the box' (tm). Take the USB printer and move it onto the home server running Centos 5.9, so that I can share it with the mrs' macbook and my desktop/laptops etc.
Here's the hurdles encountered and the fixes, so my future self won't have to waste time on this again.
Restoring Wordpress backups to a new host.
I've helped out a friend with their website recently, and it made me realise how difficult technology can still be for people who don't do this on a daily basis. Even smart people - she has a background as a professional scientist, artist and now successful businesswoman - can still require help with what on the surface appears to be the simple task of moving a website created on her mac using MAMP to the hosting company.
Although it's not hard it requires an understanding of how things fit together so here's a script I came up with for migrating her production site. I practised by restoring a wordpress backup to a clean CentOS/RHEL 6.4 server in EC2. The information was gathered from lots of blog posts, the Wordpress Codex, Mysql docs and some trial and error.
A quick post.
We have some home made cheapy frankenstorage, thats based around a low end celeron class desktop CPU. This is fine for moderate raid work, but recently I had to shovel a few terabytes between them, over the network. Making that run quickly enough led to a bit of experimentation with the speeds of the different ciphers.
Some times its hard to find a way of explaining to the technically less literate the power that the Unix shell hands you. The original ideas behing the combination wordprocessor and programmers work bench combined with the power of pipes make text processing easy.
So to today's problem - analysing GC logs for latency spikes. As we run the jvm with the following properties;
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime \ -XX:+PrintTenuringDistribution -Xloggc:/path/to/gc.logfile
I settled on piwigo for a web photo gallery, after the demise of ZangZing. I looked at the others and I'm aware that most people use twitbook for sharing family photos, but I don't really trust them with my data in the long term. Plus I'm just too much of a DIY dinosaur to use any of the modern trendy sites like candygram or whatever.
So here's a short list of pitfalls I encountered whilst getting piwigo up and running, including video.
Tinola was off the air for a couple of days due to a double fault. By which I mean I lost the primary and backup systems in the same powercut. Arguably they should have been in different datacentres. Nonetheless its unusual to get that unlucky, and now I'm considering how to move forward on the hosting front.
The new server is smaller than the old one, and after restoring from backup, getting Zimbra up and running required some manual tweaks. So this what I found out myself and from various other blogs and web pages on how to make Zimbra run on a low memory system.
It is hard to let things go sometimes.
Porting Linux to the VAX architecture taught me a lot about the detail of how Linux works, as well as how computer hardware and operating systems interact. It both removed the air of mystery about the kernel, and opened my eyes to the complexity of the GCC compiler and toolchain.
The VAX architecture is simple and easy to understand for a beginner - so much so, that when I started there were several good computer science text books which used it as a teaching system/example. I still have one or two of them on my bookshelf.
All in all it was an ideal first computer to learn operating system systems programming with, in the same way that the Talbot Horizon I had at the same time taught me about how engines and cars work - and that rust does not make an effective conductor.
It really shouldn't be this hard.
Some aspects of linux have the reputation of being hard. Traffic control via queueing disciplines for bandwidth management for example. Even the title is enough to strike fear into the heart of a seasoned system admin.
Which is a pity really, as the things outlined in chapter 9 of the lartc are very useful in practise. The problem is the documentation is very descriptive - which is good once you know roughly what you're doing - but which has quite a steep learning curve if you don't. In fact it's pretty vertical if you don't already know quite a lot about networking. A few more worked examples would help over and above those in the cookbook.
Instead, like most people in a rush, I have relied on attempting to bash together snippets of code that are on random blogs to make /sbin/tc do what I want it to do, without really understanding what is going on.
This time, when presented with a problem for which this is the exact tool, I found I needed to dive deeper, and actually understand it, as none of the precanned recipes worked. It was a case of "if all else fails try the manual".
So now I think I've got a vague handle on what is going on, I'm documenting what I ended up doing because I'm sure I will need a worked example when I come back to this in the future. If its useful to you too, so much the better.