New Internet connection - Fiber to the Home
Friday, May 2. 2014
My blog has been on a low maintenance mode, due to the fact that I had other engagements. I was moving to a new house which has an FTTH or Fiber to the Home -connection.
The incoming connection is a 1000BASE-BX Ethernet and the connection carries also a IPTV streams in it. Of the given 1 Gbit/s I'm currently purchasing 250 Mbit/s downlink and 50 Mbit/s uplink. This costs me ~60 € per month. Not very expensive for such a quality bit, huh? There is a one-time building cost for 1800+ € for the connection, but that is not slowing me down.
In detail the connection is implemented with an Ethernet fiber to copper media converter and a CATV-module doing IPTV to DVB-C (SD-channels) and DVB-C2 (HD channels) media conversion. During the setup, the fiber-guy first built couple of meters of indoors cabling connected to the thick ground fiber. Indoor fiber connects to a Swedish made Inteno FG500 box. It looks like this:
In the first picture, there are 4 gigabit Ethernet (copper) connectors and a power connector to the CATV-module. Ethernet ports 1 to 3 are routed with a firewall and NAT, but luckily the port 4 is a bridged one and that's the one I'm using. From that I can get a public IP-address directly from ISP's DHCP-server.
The box splits into two halves, CATV and the "regular" Ethernet part. Parts are connected via power and fiber connectors:
The router has internal IP-address of 192.168.1.1 and it contains very typical web-interface for managing the box. Management looks like this:
WAN-parts are configured to copper Ethernet-ports with interface grouping:
It took me a while to figure all this out. It really matters to which LAN-port the cable is connected to. The WLAN-part can be deactivated and I did just that. I dislike those integrated crappy boxes very much, they are unreliable, insecure and what else ... Being a Linux-man I want to use my favorite Linksys and DD-WRT for any wireless needs.
This has got to be the best part of having a FTTH. The speed! 
Oh my god! Here are some sample results:
When analysing the results, two things come to my mind. First, Speedtest.net and the measuring servers it has don't go beyond 100 Mbit/s in any conditions (the software displays a maximum of 100 Mbit/s in it). Second, when measuring really fast speeds like I have here, the measurements are very unreliable and the results vary quite a lot when running number of tests in a sequence. In all cases, the downlink measurement is never 100 Mbit/s or even near it. 88 Mbit/s is pretty far from 100, or from the 250 Mbit/s what I'm paying. The uplink measurements are even worse. Those servers don't expect to be hit that hard (perhaps they see a DoS-burst?). Finally, ping 0 ms does not sound very reliable either. I'd assume 2-3 ms to be a best reading in the optimal conditions.
I've been running with this connection for a couple days only, but the assumption is that the uptimes it can keep are amazing. An ADSL-connection is pretty stable, but a fiber should be the rock-solid way to go, that's what I'm expecting from it.
Update Oct 2014:
Speedtest.net indeed goes beyond 100 Mbit/s:
APC Smart-UPS battery change
Monday, April 14. 2014
My home Linux box is always on and to make sure it stays on I have an uninterruptible power supply for it. APC is very well supported in Linux by open-source apcupsd. Pretty much all other UPSes are supported by NUT, but for some strange reason APC has a separate project.
Update 20th May 2018: There is a new post about APC UPS batteries here.
Couple days ago the UPS started to beep. My house had electricity and there was no apparent fault. Except that I got an e-mail from apcupsd "UPS battery needs changing NOW". Aow crap! The batteries had reached their end of life. I confirmed the status with apcaccess and got status of:
STATUS : ONLINE REPLACEBATT NOBATT
Every 12 hours, the UPS releases a burst of beeps and I find that very annoying. It was time to go shopping for new batteries. Luckily my unit uses Replacement Battery Cartridge #7, which is popular and generally well available and the price ~200 € isn't too bad. The next thing is to get the old ones out and new ones in. APC user's manual says that battery pack is hot-swappable, so it should be an easy thing to do. Apparently the first thing to do is remove the front cover:
It has nice holes on the sides. I guess the idea is to put your fingers into them an pull hard.
When the front cover is loose, a ribbon-cable and a metal cover is revaled.
There are two phillips-head screws to hold the metal cover in place:
When the metal cover is removed, the battery pack is visible:
There is a plastic tab at the bottom. I guess it is there, so that batteries can be pulled out. Now that the metal cover is removed, the batteries are not attached to anything:
The final thing to do is to disconnect the battery pack:
Now the UPS keeps beeping a lot. It is annoyed by the fact, that it cannot find a battery. Since I don't have any original APC software on my computer I found out that the audible beep can be silenced. First make sure that the apcupsd is not running:
systemctl stop apcupsd.service
Now the apctest can be used to change any of the UPS-parameters:
# apctest
2014-04-14 20:42:05 apctest 3.14.10 (13 September 2011) redhat
Checking configuration ...
Attached to driver: usb
cable.type = USB Cable
mode.type = USB UPS Driver
Please select the function you want to perform.6) View/Change alarm behavior
Current alarm setting: ENABLED
Press...
E to Enable alarms
D to Disable alarms
Q to Quit with no changes
Your choice: Select function: d
New alarm setting: DISABLED
Now there is the blissful silence. It is much nicer to operate with the new battery pack.
Obviously the idea is to reverse the instruction. Connect the new battery, slide it in and tighten the screws and attach the front cover back.
I guess, the new battery should last at least 3 years before I'll be getting a completely new UPS. There simply is no point in running a really old UPS with brand new batteries. I guess the UPS technology will still evolve so that a new tech is required after half a decade.
Long live Windows XP: Building a Windows 7 desktop from scrap heap
Tuesday, April 8. 2014
Today, this tuesday, is the last time Windows XP gets security updates from Microsoft. Apparently Dutch and UK governments are willing to pay seven figure sums per year to keep their XPs running, but the rest of us, anything smaller than a government we don't get to have those. Last autumn I visited Windows 8.1 release in Helsinki and there a Microsoft MVP said "Microsoft is not that evil company, they just might release something really critical if it comes down to that". There was some chuckling in the crowd. Anyway, very interesting things will happen to XP, see the CVE-list for non-fixed flaws.
In Finnish media, the XP has gotten a lot of media coverage all year. I guess it got to the point of scaring regular users in the national TV. This I figured when my mother called me about her Windows 7. The another thing was at my neighbor's computer. She has an old XP-box with really poor specs. She asked for my help, but after initial assessment there was nothing I could do with her old computer. I happened to have an old Dell OptiPlex GX260 desktop computer with steroids, a SSD-drive in a ATA-to-SATA -adapter. I was about to do the decent thing and comply with EU 2002/96/EC directive, aka. throw the electronic junk where all electronic junk ends up at. The computer has only 512 MiB memory, but given the 2,0 GHz Pentium 4 CPU, it runs 2009 released Windows 7 in a reasonable acceptable manner. The best part for my neighbor was, that I promised to donate the hardware free of charge. It was only a matter of getting a license key for Windows 7.
My old OptiPlex booted from installation DVD without problems, I must say I was amazed about that. Any old low-quality CD/DVD-drive typically has issues with dust in the lens and the read head eventually deteriorates to the point, that the drive refuses to read anything. Anyway, the Windows 7 installer found the SATA-connected SSD-drive, the installer copied the files, booted for the initial Out-Of-the-Box-Experience. Everything seemed to be ok, I had network connectivity and even some sound.
What every legacy PC does after install is, that the display resolution is something unbelievable. This case I had a VGA 640x480. It sure looked nice on my 22" LCD-screen!
The thing is: no W7 drivers for my Dell. It seems to have a built-in Intel 82845G graphics adapter in it. The Dell support knows about my machine and the display driver in its Download Center, but the latest supported OS they have is Windows XP. WDDM driver model was introduced in Vista and XDDM drivers was the last one Intel ever did for 82845G. This was confirmed in Microsoft TechNet's Windows 7 IT Pro forums discussion How do I get Windows 7 Graphic driver for the Intel 82845G Graphics Controller?
Lucky for me, somebody had posted a link to another article For Older Hardware to Run on Windows 7 How to Install intel 82845G graphics driver on Window 7, and there was a solution for my exact problem. I didn't realize that it was possible to still use XDDM drivers, but it is possible. In device manager, there is a Add Legacy hardware:
I took the 82845G driver package 14.10.3, unzipped it and Windows 2000 XDDM driver installed. After rebooting the Windows 7, everything was ok. The driver actually claims it can go up to 2048x1536, but given the analog VGA-connector I chose not to go that far.
Finally, I installed Microsoft Security Essentials into it and I was done. My neighbor had a nice "new" computer till year 2020. I'm wishing people would upgrade before that, but knowing that doing nothing is always the preferred action on non-hackers, so plenty of people will be taken by surprise when Windows 7 updates run out.
Fixing Postfix: Make mail exit your Linux-box
Monday, April 7. 2014
Polkomtel firmware for u-12
Sunday, April 6. 2014
What is netsession_win.exe and what it is doing in my Windows?
Thursday, April 3. 2014
EPIC4 maildir patch
Sunday, March 30. 2014
Fixing inaccurate Windows 7 NTP-client
Saturday, March 29. 2014
3 Italy firmware for u-12
Friday, March 28. 2014
Wrangling permissions on an enforcing SElinux setup
Saturday, March 22. 2014
Most people don't much care about their Linux-boxes' security. You install it, you run it, you use it and occasionally run some system updates into it. Not me. When I have a box running against the wild wild Net, I absolutely positively plan to make the life of anybody cracking into one of my boxes as difficult as possible (with some usability left for myself). See Mr. Tan's article about Security-Functionality-Usability Trade-Off.
So, my choice is at the Functionality - Security -axis with less on the Ease-of-use. The rationale is that, a web application needs to run as safely as possible and can have the ease-of-use in it. The system administrator is a trained professional, he doesn't need the easy-part so much. However, there is a point, when things are set up too tight:
Image courtesy of Dilbert by Scott Adams
So, I voluntarily run software designed and implemented by NSA, SElinux. I even run it in the the Enforcing-mode which any even remotely normal system administrator thinks as being totally insane! Any small or even a tiny slip-up from the set security policy will render things completely useless. Mordac steps in and stuff simply does not work anymore.
On my Fedora-box there was a bug in BIND, the name server and an update was released to fix that. After running the update, the DNS was gone. As in, it didn't function, it didn't respond to any requests and the service didn't start. All it said was:
# systemctl status named-chroot.service --full
named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled)
Active: failed (Result: timeout)
Any attempt to start the service resulted in a 60 second wait and a failure. dmesg-log had nothing about the issue, nor BIND's own log had nothing about the issue in it. So I started suspecting a SElinux-permission issue. My standard SElinux debugging always starts with a:
cat /var/log/audit/audit.log | audit2allow -m local
... to see if SElinux's audit logger is logging any permission-related audit faults. Indeed it did:
require {
type named_conf_t;
type named_t;
class dir write;
}
#============= named_t ==============
allow named_t named_conf_t:dir write;
That reads:
A process running in named_t security context is trying to access a directory with named_conf_t security context to gain a write access, but is denied while doing so.
It is obvious that the process in question must be the BIND name server. No other process has the named_t security context in it. When starting up, BIND name server was about to write into its own configuration directory, which is a big no no! When you write, you write only to designated directories, nowhere else (remember: running in enforcing-mode is insanity).
That is definitely a reason for a daemon not to start or to timeout while starting. Further investigation showed that also Fedora's SElinux policy had been updated a week ago: selinux-policy-3.12.1-74.19.fc19.
At this point I had all the pieces for the puzzle, it was simply a matter of putting it all together. The recently released SElinux policy has a bug in it, and nobody else was there to fix it for me.
The exact audit-log line is:
type=AVC msg=audit(1395481575.712:15239): avc:
denied { write } for
pid=4046 comm="named" name="named" dev="tmpfs" ino=14899
scontext=system_u:system_r:named_t:s0
tcontext=system_u:object_r:named_conf_t:s0 tclass=dir
So, my chrooted BIND-damon was trying to write into a tmpfs. There aren't that many of those in a system. I've even touched the tmpfs-subject earlier when I wrote a systemd-configuration into my own daemon. To find the tmpfs-usage, I ran:
# mount | fgrep tmpfs
tmpfs on /var/named/chroot/run/named type tmpfs
BIND's chroot-environment has one. That is very likely the culprit. That can be confirmed:
# ls -Z /var/named/chroot/run/
drwxrwx---. named named system_u:object_r:named_conf_t:s0 named
Yep! That's it. The directory has incorrect security context in it. To compare into system's non-chrooted one:
# ls -Zd /run/
drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /run/
There is a difference between named_conf_t and var_run_t. You can write temporary files into latter, but not to the first one. The fix is very simple (assuming, that you speak fluent SElinux):
semanage fcontext -a -t var_run_t "/var/named/chroot/run(/.*)?"
restorecon -R -v named/
The two commands are:
First, re-declare a better security-context for the directory in question and then start using the new definition. Now my BIND started and was fully operational! Nice.
My investigation ran further. I needed to report this to Fedora-people. I looked into the policy-file of /etc/selinux/targeted/contexts/files/file_contexts and found the faulty line in it:
/var/named/chroot/var/run/named.* system_u:object_r:named_var_run_t:s0
That line almost works. The directory in question has only two files in it. One of them even has a matching name. The problem, obviously, is that the another one does not:
# ls -l /var/named/chroot/run/named/
total 8
-rw-r--r--. 1 named named 5 Mar 22 12:02 named.pid
-rw-------. 1 named named 102 Mar 22 12:02 session.key
See Bug 1079636 at Red Hat Bugzilla for further developments with this issue.
Disabling non-disableable Internet Explorer add ons
Friday, March 21. 2014
One day my laptop shut itself down while I was getting a cup of coffee. No big deal, I thought. I'll just plug it into charger and things will be ok again. It took me by surprise to see, that the battery was 80% charged and the laptop had done a "crash landing". Apparently it chose to turn itself off. I'm guessing to avoid an over-heating situation.
Couple of weeks later I realized that a machine that does not do anything, chews about 25% CPU constantly. The natural guess would be a virus scanner, but it turned out to be a process called IEWebSiteLogon.exe:
I've never heard of such an application. Google didn't reveal anything useful, but the process properties revealed that the file was located at C:\Program Files\Lenovo Fingerprint Reader\x86\, so the conclusion is that my fingerprint reader's software is running a piece of software to eat up a lot of CPU-resources to do exactly nothing.
The file name gave me a hint, that it has something to do with Internet Explorer. I was running IE 11:
I opened the add ons manager:
and there it was. My initial idea of disabling the stupid thing didn't pan out. The Disable-button is grayed out. Searching The Net revealed two interesting pieces of information: How to Remove Unneeded Plug-Ins in Internet Explorer By Andy Rathbone from Windows 8 For Dummies, which proved to be useless, it instructs to disable the add on. The second yielded results: Can't remove Internet Explorer Add-On. It described a way to track down the component by its class ID. Nice, but not nice enough. Somewhere there is a piece of code to attempt to load the missing component. Why not remove the requirement?
The details of the add on are:
Now I had the class ID of {8590886E-EC8C-43C1-A32C-E4C2B0B6395B}. According to SystemLookup.com is a valid piece of software, they say: "This entry is classified as legitimate". That class ID can be found in my Windows system's registry from the following locations:
- HKEY_CLASSES_ROOT\CLSID\
- HKEY_CLASSES_ROOT\Wow6432Node\CLSID\
- HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\
- HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Approved Extensions
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\
The interesting ones are the system setting of Browser Helper Objects and user setting of Approved Extensions. Removing the helper object surely will disable the add on completely. Also it will be a good idea to make it a not-approved extension. And to un-register the component. All that should give the stupid add on a decisive blow and make it not waste my precious CPU-cycles.
The following PowerShell-commands run with administrator permissions will do the trick:
Remove-Item -path
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
Remove-Item -path
"HKCU:\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
Remove-ItemProperty -path
"HKCU:\Software\Microsoft\Internet Explorer\Approved Extensions" -name "{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
If you don't have admin-permissions, the commands will fail. Also please note that every time Internet Explorer is started, it will make sure that permissions in the registry HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Approved Extensions are set so, that user is denied any modification access. See this:
I tried to remove the deny ACL with PowerShell, but it seems to be impossible. The API is not mature enough.
After removing the deny ACL and running the PowerShell-commands and finally stopping and starting the Internet Explorer, the add on was gone. I managed to "disable" it completely.
PHP large file uploads
Thursday, March 20. 2014
Trivial mod_rewrite: Redirect to another file in the same directory
Wednesday, March 19. 2014
I found a funny quote at Htaccess Rewrites - Rewrite Tricks and Tips, it says:
``Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo. ''
-- Brian Moore
bem@news.cmc.net
The quote is originally at http://httpd.apache.org/docs/2.0/rewrite/. Now obsoleted documentation for old Apache version.
I'll have to second Brian's opinion. I've touched the subject earlier at Advanced mod_rewrite: FastCGI Ruby on Rails /w HTTPS.
My YUM-repo definition RPM had a bug in it (see: CentOS 6 PHP 5.4 and 5.5 yum repository) and I had to release a new version of it. There exist already couple of links to the file. Why didn't I think of a situation where an update is released? Darn! So, let's keep the URL alive, even if a new version of the file with different name is released. That way everybody stays happy.
Attempt 1: Failure
An over enthusiastic "hey, that should be simple!" -type of naive solution. Create a .htaccess-file into the appropriate directory with content:
RedirectPermanent oldname.rpm newname.rpm
Well ... no. The result is a HTTP/500 and in the error log there was a:
/home/the/entire/path/here/.htaccess: Redirect to non-URL
Ok. It didn't work.
Attempt 2: Failure
Let's ramp this up. Forget the simple tools, hit it with mod_rewrite! Make .htaccess contain:
RewriteEngine on
RewriteRule ^oldname\.rpm$ newname.rpm [R=301]
Well ... no. The result is a HTTP/404, because the redirect goes really wrong. The result will be http://my.server.name/home/the/entire/path/here/newname.rpm, which is pretty far from being correct. There is a funny mix of URL and the actual filesystem storage.
The reason can be found from the Apache docs at RewriteRule PT-flag:
"The target (or substitution string) in a RewriteRule is assumed to be a file path, by default. The use of the [PT] flag causes it to be treated as a URI instead."
and
"Note that the PT flag is implied in per-directory contexts such as <Directory> sections or in .htaccess files."
That phrase can be translated as:
- Internally RewriteRule works with filesystem paths
- When using RewriteRule from a .htaccess-file it does not use filesystem paths, but URLs
- A .htaccess-file really messes things up
Something more elegant is obviously needed.
Attempt 3: Failure
I studied the Apache docs and found a perfect solution! What about if there was a way to discard the filesystem path entirely. Nice! Let's go that way, make .htaccess contain:
RewriteEngine on
RewriteRule ^oldname\.rpm$ newname.rpm [R=301,DPI]
Well ... no. I have the DiscardPathInfo-flag there, but it changes absolutely nothing. It is the same with or without the flag. It clearly says that "The DPI flag causes the PATH_INFO portion of the rewritten URI to be discarded" in the docs. Apparently the flag is used for completely different thing (which I'm having hard time to comprehend), but the thing is that I cannot use it to fix my redirect.
Attempt 4: Success!
After browsing the Apache-docs even more I struck gold. The docs for RewriteBase-directive say:
"This directive is required when you use a relative path in a substitution in per-directory (htaccess) context"
and
"This misconfiguration would normally cause the server to look for an "opt" directory under the document root."
That's exactly what I'm doing here. I have a relative path. I'm using a substitution in a .htaccess-file. It even mis-behaves precisely like in the example from the docs.
The solution is to make .htaccess contain:
RewriteEngine on
RewriteBase /path/here/
RewriteRule ^oldname\.rpm$ newname.rpm [R=301]
Now it works exactly as I want it to do! Nice!
When a request is done for the old filename, Apache will do an external redirect and notify browser about the new version. wget fails to save the file with the new name (it will use the old name), but for example Firefox does that correctly.
Conclusion
Darn that voodoo is hard.
The mod_rewrite's complexity simply laughs at any system administrator. I consider myself to be one of the experienced ones, but still ... I find myself struggling with the subject.
Cisco ASA protected SSH-connection hangs - [Fixed]
Thursday, March 13. 2014
Using own SSL certificate in Cisco ASA
Tuesday, March 11. 2014
Yesterday I was mighty pissed about Oracle's Java breaking my stuff. Then it occurred to me: I shouldn't be using self-signed certificates in the first place! See my post about Certificate Authority setup: Doing it right with OpenSSL, where I wrote "My personal recommendation is to never use self-signed certificates for anything". And there I was! Darn. 
I figured, that there must be a way of stop the stupidity and install an own certificate to the network appliance. Then I bumped into ASA 8.x: Renew and Install the SSL Certificate with ASDM, a PDF-document from Cisco instructing how to achieve that. Nice! Exactly what I needed.
This is how to do it. Log into ASDM and go to Configuration -> Device Management -> Certificate Management -> Identify Certificates. It looks like this:
There you can find Add-button:
You should add a new identify certificate. I used the Default-RSA-Key, but Cisco's own documentation says to generate a new one. In case SSH-keys need to be regenerated, the SSL-certificate won't work anymore. In my case I can simply recreate the certificate also, so it is not an issue to me. After you click Add Certificate:
You will get a dialog to save the Certificate Signing Request (CSR) into a local drive to be sent to a Certification Authority (CA) to be processed.
After your CSR has gone trough and you have your certificate in PEM-format go back to ASDM and select Install this time. You will get a dialog:
Upload or copy/paste the PEM certificate there and click Install Certificate. After that you'll have an identity:
Now the next thing to do is to start using the newly created identity. In Configuration -> Device Management -> Advanced -> SSL Settings there is an option to choose an identity to use when ASDM is being accessed via HTTPS or ASDM-IDM.
To get better results from Qualsys SSL Labs server test I did following changes:
- SSL-version is set to TLS V1 Only, that is TLS 1.0 only. 1.1 nor 1.2 is not available.
- For encryption I'm only using:
- 112-bit 3DES-SHA1
- 128-bit RC4-SHA1
- 128-bit RC4-MD5
- The AES-encryptions for 128-bit or 256-bit failed on my box for some reason. If you have them, please use those! The chosen 3 crypto algos provide reasonable security, but the AES-ones are better.
After an Apply the new certificate is in use. You can verify that via a web browser from HTTPS-interface or go to Control Panel's Java security settings and remove the self-signed certificate from secure site certificates -list. The ASDM-login will work again.
