Back to Newsletters
KEYWORDS=ldup,MikroTik,elgg Davrom Consulting Newsletter - Issue # 53 - Dated: 19 Jul 2013
From the desk of David Clark
Time for a newsletter given six months or so have passed... and the
newsletter is often written at the odd times of the night or very early
mornings as time permits.
An old colleague of mine used to say, "So much Unix, so little time".
There is less focus on newsletters now we are releasing a regular podcast
instead, the Linux Down Under Podcast (ldup), and you can subscribe to it
with iTunes or go directly to our site:
which contains the rss feed file, mp3 files and show notes. This is very
early days for us but I am enjoying adding a 'voice' to the Linux industry
no matter how small mine is in the vast expanse of the Linux universe. :-)
There is always a struggle when releasing technical information such as
newsletters and podcasts, trying to strike the "happy medium" of not being
too technical but also not too light on for those who can work with what you
are presenting, and not giving away the know-how that helps you stay in
Support work continues to be constant text to PDF and e-mailing the
resulting PDF and the current work-load/demand for this continues.
Keeping older application systems alive with virtualisation solutions
continues to be a common need as well.
I would like to thank the reader for their time in reading this
Android, now the largest distribution of Linux.
Since the demise of SnapGear which was a core product of what we supplied
and/or supported, following some initial testing of alternatives that were on
par with SnapGear quality and technical capabilities, we have begun to
implement MikroTik routers for customer sites and are running one on our
ADSL2 link in-house as well.
Like the SnapGear and Cyberoam products, the MikroTik requires an ADSL modem
set in bridge mode to be connected in front of it for Internet connection.
For the most part our focus has been to ensure customers have a secure
Internet firewall that provides some basic services with the main one being
port forwarding to servers and PCs within the LAN behind it from the
Internet. It also has a full DHCP server for automatic LAN IP address
Another key component that most of our customers need is the ability to
remotely connect into their office via VPN, mainly still using the PPtP VPN
protocol. To this end the MikroTik has serviced this need very well from a
myriad of devices and PCs. (for Mac OSX it appears you do need to add a
static route but this issue does not exist for other Apple devices, nor is
it required for Windows or Linux VPN connections).
Another core feature is to be able to connect remote offices over the
Internet to result in a company WAN solution and again the MikroTik supports
the usual IPSec, L2TP, OpenVPN and connections to Cisco PIX firewalls.
The interfaces for setting up the MikroTik can be command line via
telnet/ssh, web interface or using their own Winbox utility.
Setup is straightforward and the diagnostics you can get from these devices
are quite extensive with most setup screens for interfaces and such like
showing you active stats as you configure them.
Overall an excellent device but the key benefit is the price being around
$120-$180 inc GST and freight RRP from suppliers.
Certainly a highly affordable fully featured product that puts it at an
extremely competitive edge against the big/top router players.
ELGG private community system
I saw an article that the ELGG free open source on-line community system was
available and decided to quickly load and test this on our web server to
see if I could further use this kind of solution with some of the Internet
groups I am part of.
ELGG is ideal for groups of on-line people to belong to a kind of community
forum, blog and file sharing system, much in the same vein that solutions
like Facebook were modeled on.
This system would be ideal for specific community work groups who want to
keep all of their messaging, fileshare and blogging between other users on
the system private.
It provides the usual friends lists to allow and follow as well as having
full e-mail updates to your public e-mail address on any updates that occur
within ELGG such as someone adding to a post you have submitted,
acknowledging you as a valid contact, or leaving you an on-line message.
While it would not replace something like Facebook, it certainly would
service the need for a group of people who wish to communicate on-line in a
private forum all safely housed on your own Linux server.
From the Trenches
Some comic or not so comic relief from the support days gone by.
I recall having to go to a site to check a SCO Xenix server running on a
Powermate2 286 server in the late 1980s.
The server, after a fair time in service, had started to panic and the
information we were able to glean from the details was that the issue was
memory (RAM) related.
Given supply of the memory boards and chips were sometimes delayed, I was
sent to the site to do a possible memory fix that did not require parts
In the early memory board days, PCs shipped with a memory board with a base
amount of memory installed on it and to then expand this memory you had to
populate the board with small memory chips resembling metallic caterpillars.
I removed the memory board after downing the server and allowed the board
to cool. I then proceeded to carefully push down on each chip and some
actually clipped further into place. I made sure all the chips were firmly
seated, installed the board again and booted the server.
And this was the end of its memory panic issues.
Over time the chips had an issue called 'heat creepage' which meant as the
board heated up the metal contact legs on the actual individual memory chips
sometimes moved out of position enough to distort the memory count (which
you could see with the boot messages on the server) and this caused the
operating system to have issues.
Stopping a file being modified outside of the usual chmod/umask rules:
I recently had a need to keep the /etc/resolv.conf file (the file that
contains DNS information) from being modified by a system updater which
sometimes changed the contents of this file.
As the automated updating task was running as the root user, it was a little
hard to prevent the automatic update process and given I didn't necessarily
want to completely stop this service, just prevent its changes to one file.
chattr to the rescue.
If you run:
chattr + filename
(in my case /etc/resolv.conf)
you are preventing this file from being modified even if the particular user
has the user/system permissions ability to do this.
To set the file to be able to be modified again, use the command:
chattr - filename
Back to Newsletters
Website design by Davrom Consulting Pty Ltd
This site is fully tested with Google Chrome and Firefox web bowsers
Home Page | Support | Misc | David's Pages | Podcasts | Contact Us | Blog