Explaining why I've been so quiet lately: Migrating data and upgrading the software that runs the blogs and farm site (plus a bunch of other stuff) to a new server. Yay upgrade! Boo problems! Just in time, too, it would seem, since the old server started mysteriously and frequently rebooting for no good reason, so I'm pretty sure that its been down more than its been up for about ten days now. :-(
Sorry if its all been very dodgy.
If anybody notices anything noticably untoward, please let me know -- I think I've moved everything over successfully, but not yet 100% sure, but, with the old server dying, I just want everything off it as soon as possible, so haven't had time to test all my new configuration properly.
Showing posts with label systemadmin. Show all posts
Showing posts with label systemadmin. Show all posts
05 June 2011
13 September 2010
Setting up a PPTP VPN with KDE NetworkManager
Filed under "Notes to Myself". If this helps someone else out there, Good!
The problem: to VPN into a closed Microsoft-dominated network.
After 6 weeks of hacking at it, the client's network administrator finally managed to get the VPN set up on their office server (some version of Windows is involved, so no wonder it is an opaque and difficult process taking weeks and involving numerous reboots. I am frequently moved to wonder whether people actually enjoy the pain that results from using Microsoft software... I can't think of any other reason to use it.)
So it helps to have the admin tell you:
The rest of the trouble comes from Kubuntu Linux insisting on using the fucked-up awful NetworkManager. I could not find reliable/working information on setting up the correct config by hand, so was forced to rely on NM. Also tried Kvpnc, but could not make it work for the client network configuration.
NM insists on setting the default route for all network traffic to be via the VPN client network. Not what I want. I need on-going access to my own local network resources as well as the VPN resources (as well as my own internet connection) as I am developing stuff that relies on local resources to work. After starting the VPN, my machine's routing table looks like
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
(192.168.1.0/24 is my own local net; 192.168.0.0/24 is the client's network.)
Note that last line. There's the troublemaker. I don't want all traffic routed to the VPN by default. I tried every possible combination of settings in the KNetworkManager applet, especially those that claim to prevent the VPN from overriding the automatic routing. I tried manually setting all the VPN info (IP address, netmasks, etc.) but that fails to work either.
Ultimately I resorted to a workaround. Accept the crappy routing that NM sets up for me, then fiddle with the routing tables by hand:
$ sudo route del -net 0.0.0.0 ppp0
$ sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.1.254 dev eth0
These 2 lines get me a sensible default route outta here, and
$ sudo route add -net 192.168.0.0 netmask 255.255.255.0 dev ppp0
gets me a route to all the client-network resources (albeit without any DNS lookups for their subdomain; this I can live without, since there are only a small handful of machines I need access to.)
The resulting routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
Can't say it's pretty, but it works.
The problem: to VPN into a closed Microsoft-dominated network.
After 6 weeks of hacking at it, the client's network administrator finally managed to get the VPN set up on their office server (some version of Windows is involved, so no wonder it is an opaque and difficult process taking weeks and involving numerous reboots. I am frequently moved to wonder whether people actually enjoy the pain that results from using Microsoft software... I can't think of any other reason to use it.)
So it helps to have the admin tell you:
- the gateway address for the VPN
- your username and password
- the VPN protocol is PPTP (MS proprietary AFAICT) and
- that it requires some (MS peculiar) encrytion scheme (MPPE) to be used.
The rest of the trouble comes from Kubuntu Linux insisting on using the fucked-up awful NetworkManager. I could not find reliable/working information on setting up the correct config by hand, so was forced to rely on NM. Also tried Kvpnc, but could not make it work for the client network configuration.
NM insists on setting the default route for all network traffic to be via the VPN client network. Not what I want. I need on-going access to my own local network resources as well as the VPN resources (as well as my own internet connection) as I am developing stuff that relies on local resources to work. After starting the VPN, my machine's routing table looks like
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
(192.168.1.0/24 is my own local net; 192.168.0.0/24 is the client's network.)
Note that last line. There's the troublemaker. I don't want all traffic routed to the VPN by default. I tried every possible combination of settings in the KNetworkManager applet, especially those that claim to prevent the VPN from overriding the automatic routing. I tried manually setting all the VPN info (IP address, netmasks, etc.) but that fails to work either.
Ultimately I resorted to a workaround. Accept the crappy routing that NM sets up for me, then fiddle with the routing tables by hand:
$ sudo route del -net 0.0.0.0 ppp0
$ sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.1.254 dev eth0
These 2 lines get me a sensible default route outta here, and
$ sudo route add -net 192.168.0.0 netmask 255.255.255.0 dev ppp0
gets me a route to all the client-network resources (albeit without any DNS lookups for their subdomain; this I can live without, since there are only a small handful of machines I need access to.)
The resulting routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
Can't say it's pretty, but it works.
10 September 2009
Network Disasters Happen in Threes Fours
Only 9 more sleeps to go...
Strike 1: Last week, disaster struck in the form of a 2-day DSL outage. Telkom -- my current DSL provider -- blithely went and cleared the fault ticket after 24hours -- without any consultation with me -- because their test centre said that my router was getting a connection to the local exchange. The ticket comment was, "Fault closed at customer request." Liars!
Much wailing and gnashing of teeth later, they discovered that a whole lot of people in the area were experiencing the same problems: very sporadic connectivity with almost no traffic getting through. Turned out to be a fault on the exchange itself.
Strike 2: On the same day that this problem started, my London-housed server went down for Reasons Unknown. Of course I was blissfully unaware of it until Friday. 2 days of server outage. Then my service provider there was terribly slow to rectify the problem (which -- as the universe will insist upon -- involved a fractal nesting of sub-problems with their own sub-sub-problems ad mandelbrot.) As I write, the server is still only partially up. Apache service -- the one my paying customers rely on -- is up and working fine on one IP address, but Tomcat, hosting my personal and "corporate" sites, blogs and wikis still cannot talk through the other IP address. The service I get from VAServ is pretty kak, but not so kak as to be noteworthy -- they really are giving me a very low-cost package, and, as always, You Gets What You Pays For.
Strike 3: At the same time an FTP backup service I use for offsite backups refused to authenticate me, using the same credentials I've been using for years, with the result that I could not even ensure the safety of all the data! Be Still, My Twitching Ulcer.
You're Out: Welcome to this morning, where we present -- for your entertainment and edification -- a reprise of last week's DSL outage. Telkom, predictably, and once again, are in complete denial that there is actually a problem. Their tests show a solid connection between my router and their exchange. No shit, Sherlock! Pity the bits can't squeeze through the tiny opening.
I've always been very happy with the ISP service I've received from WebAfrica, and have, over the years, put many friends and colleagues onto them, not one of whom has had anything less than Sterling service. I've asked WA to take over my DSL service1, too, in light of recent events. The only bit of business Telkom will be getting from me for the foreseeable future will be POTS.
Only 9 more sleeps to go...2
I think this sorry whining actually has a point; it tends to back up my long-held belief that telcos are constitutionally incapable of competently running IP services. The cultures and philosophies that make end-to-end controlled networks are unable to comprehend -- in some weirdly deep, DNA-level way -- how to cope with IP networks which have almost no intelligence in the middle, but live, instead, with all the intelligence at the edges.
People who run IP networks, on the other hand, are able to provide perfectly adequate voice services over IP, which is why they're going to eat the telcos' lunch over the long term.
[1] There's no transfer/installation fee. Their monthly rates are at present the same as Telkom's, and as they roll out their own infrastructure, they anticipate reducing the charges. Their support desk is outstanding, staffed by people who actually know stuff, don't mind admitting mistakes and problems, treat customers like Real Humans instead of problem-id's, and follow through on promises and commitments and ensuring that things get fixed. I can't see any downside, can you?
[2] Of course, it occurs to me a little late, that I'll only be able to actually post this when I get the server working properly again. Which will only happen when I get some reasonable connectivity back. Which might happen slightly after Lucifer goes skiing from his front doorstep.
Strike 1: Last week, disaster struck in the form of a 2-day DSL outage. Telkom -- my current DSL provider -- blithely went and cleared the fault ticket after 24hours -- without any consultation with me -- because their test centre said that my router was getting a connection to the local exchange. The ticket comment was, "Fault closed at customer request." Liars!
Much wailing and gnashing of teeth later, they discovered that a whole lot of people in the area were experiencing the same problems: very sporadic connectivity with almost no traffic getting through. Turned out to be a fault on the exchange itself.
Strike 2: On the same day that this problem started, my London-housed server went down for Reasons Unknown. Of course I was blissfully unaware of it until Friday. 2 days of server outage. Then my service provider there was terribly slow to rectify the problem (which -- as the universe will insist upon -- involved a fractal nesting of sub-problems with their own sub-sub-problems ad mandelbrot.) As I write, the server is still only partially up. Apache service -- the one my paying customers rely on -- is up and working fine on one IP address, but Tomcat, hosting my personal and "corporate" sites, blogs and wikis still cannot talk through the other IP address. The service I get from VAServ is pretty kak, but not so kak as to be noteworthy -- they really are giving me a very low-cost package, and, as always, You Gets What You Pays For.
Strike 3: At the same time an FTP backup service I use for offsite backups refused to authenticate me, using the same credentials I've been using for years, with the result that I could not even ensure the safety of all the data! Be Still, My Twitching Ulcer.
You're Out: Welcome to this morning, where we present -- for your entertainment and edification -- a reprise of last week's DSL outage. Telkom, predictably, and once again, are in complete denial that there is actually a problem. Their tests show a solid connection between my router and their exchange. No shit, Sherlock! Pity the bits can't squeeze through the tiny opening.
I've always been very happy with the ISP service I've received from WebAfrica, and have, over the years, put many friends and colleagues onto them, not one of whom has had anything less than Sterling service. I've asked WA to take over my DSL service1, too, in light of recent events. The only bit of business Telkom will be getting from me for the foreseeable future will be POTS.
Only 9 more sleeps to go...2
I think this sorry whining actually has a point; it tends to back up my long-held belief that telcos are constitutionally incapable of competently running IP services. The cultures and philosophies that make end-to-end controlled networks are unable to comprehend -- in some weirdly deep, DNA-level way -- how to cope with IP networks which have almost no intelligence in the middle, but live, instead, with all the intelligence at the edges.
People who run IP networks, on the other hand, are able to provide perfectly adequate voice services over IP, which is why they're going to eat the telcos' lunch over the long term.
[1] There's no transfer/installation fee. Their monthly rates are at present the same as Telkom's, and as they roll out their own infrastructure, they anticipate reducing the charges. Their support desk is outstanding, staffed by people who actually know stuff, don't mind admitting mistakes and problems, treat customers like Real Humans instead of problem-id's, and follow through on promises and commitments and ensuring that things get fixed. I can't see any downside, can you?
[2] Of course, it occurs to me a little late, that I'll only be able to actually post this when I get the server working properly again. Which will only happen when I get some reasonable connectivity back. Which might happen slightly after Lucifer goes skiing from his front doorstep.
15 May 2009
Backups
Nice story on /. this morning about a faulty backup strategy gone wrong and its consequences. I'll bet a lot of smalltime operators are checking their backups this morning.
I know I am ;-)
I know I am ;-)
11 September 2008
Infrastructure Fix
Finally! Took a day off from preparing for the (Advanced Architecture and Design) course I'm hosting next week, and spent the time getting my local infrastructure back on its feet after a breakdown some weeks ago. Basically the LAN server died... motherboard or CPU. Suddenly we realised just how much we've come to depend on that little machine! DNS caching, plus names for all the machine on our farm-LAN1, HTTP proxy, local Subversion server, file-share, music streaming, and not to mention supplying the base-infrastructure for some Jini services that come and go as we play around with Jini and JavaSpaces.
So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result. "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?" Ding! You Do Not Win The Lounge Suite!
Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down! And maybe have a few more tiny-little servers...
[1] The term "server farm" takes on a whole new significance ;-)
[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...
So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result. "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?" Ding! You Do Not Win The Lounge Suite!
Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down! And maybe have a few more tiny-little servers...
[1] The term "server farm" takes on a whole new significance ;-)
[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...
10 July 2006
JSPWiki
I think JSPWiki is one of the greatest pieces of open source software out there anywhere. It might not be well suited to everytone running a small website on a shared host because it requires a Java servlet container for hosting, so demands a slightly higher level of expertise than the PHP junk that's out there.
That said, it drops into place and "just works" for a fast tryout or evaluation. At the same time most of the flexibility needed for large-scale, sysadmin-run deployments is easily available, and its not an "all in one big step" thing either: you can gradually add the finer-grained controls as you need them. Any Java-capable sysadmin will have no difficulty.
Furthermore, there is an active, healthy and, above all, friendly developer community.
I am using JSPWiki to run the "static" content side of this website, with only myself allowed to create, delete and edit pages. (Indeed, only I am allowed to log in!) Its perfect for the task. All I have to do now is hack the templates into something nicer to look at. :-)
That said, it drops into place and "just works" for a fast tryout or evaluation. At the same time most of the flexibility needed for large-scale, sysadmin-run deployments is easily available, and its not an "all in one big step" thing either: you can gradually add the finer-grained controls as you need them. Any Java-capable sysadmin will have no difficulty.
Furthermore, there is an active, healthy and, above all, friendly developer community.
I am using JSPWiki to run the "static" content side of this website, with only myself allowed to create, delete and edit pages. (Indeed, only I am allowed to log in!) Its perfect for the task. All I have to do now is hack the templates into something nicer to look at. :-)
27 June 2006
More website progress...
Finally managed to get the farm web content up and running under the new JSPWiki - now I just have to hack the templates to conform to the new scheme of things. The advantage is that I'll be able to secure the content-editing using the new permissions system in JSPWiki, instead of my old scheme of having two different template sets. Means I will only have to maintain one template set in future.
JSPWiki is just such a great piece of software; the guys who develop it have a fine sense of "as simple as possible, but no simpler".
JSPWiki is just such a great piece of software; the guys who develop it have a fine sense of "as simple as possible, but no simpler".
16 June 2006
mikro2nd.net Stage 2 retro rockets firing
So, Stage 2 of my experiment is now working - integration of the wiki (JSPWiki - the best wiki engine out there) with the blog system (Blojsom, in case you didn't notice, and also a best of breed piece of work). Next I'll probably fiddle with wiki templates for a while to get some working the way I want things. OTOH I don't want to drop too deep into Look and Feel issues before adding Forums. (Isn't it a pity that "Fora" is such an ugly word that almost nobody gets without blinking? Correctness sacrificed for common use.)
I'll probably go for using MVNForum, and have never yet had the pleasure of installing it, so I would really, really like to hear from anybody who has strong opinions (for or against) MVNForum, particularly from the viewpoint of installation and administration.
I'll probably go for using MVNForum, and have never yet had the pleasure of installing it, so I would really, really like to hear from anybody who has strong opinions (for or against) MVNForum, particularly from the viewpoint of installation and administration.
Subscribe to:
Posts (Atom)
