If everything is fine but this message “ntpdate: no server suitable for synchronization found” keeps coming up, then it could be your ISP blocking UDP port 123. Use ntpdate -u to verify, this option should circumvent the firewall.

References:
http://blog.haite.ch/2009/05/22/1242984900000.html

PREROUTING in mangle table: alter routing (e.g. source-based routing)
FORWARD in mangle table: traffic shaping for tc (flowid)

In MikroTik RouterOS, /ip firewall nat:
srcnat chain = PREROUTING
dstnat chain = POSTROUTING

/ip firewall mangle:
prerouting chain = global-in
forward chain = global-out (support NAT traffic shaping, higher load on router)

Update: I used to think that global-in literally means global input, while global-out literally means global output.  Apparently I was mistaken.  The parent queues MUST be matched to the right parent, either global-in, global-out, global-total, or one of the network interfaces depending on the mangle rules.  Top-most queue parent (global-in, global-out, global-total) doesn’t decide whether it’s up/down.  The mangle rules do the direction decision trick, whether a packet is incoming/download or outgoing/upload.  This makes perfect sense now! (doh)  I kept wondering why half of my queues (download queues’ top-most parent was global-in) weren’t working, when all my mangle rules were in forward chain.  Obviously they wouldn’t, because global-in marks both direction in prerouting chain.

This didn’t make sense until I read the URL listed below under References.  Silly me!  Assumption is the root of most, if not all, problems indeed.

References:
http://wiki.ispadmin.eu/index.php/Documentation/Mikrotik_guide#.22Global-in.22_vs._.22global-out.22_setup

Add a new script to the MikroTik router (replace those in bold):

• /system script add name=zoneedit-dyndns source=”/tool fetch url=\”http://dynamic.zoneedit.com/auth/dynamic.html\?host=dyndns.example.com&dnsto=127.0.0.1\” user=ZEUser password=ZEPass keep-result=no\r\n/delay 30\r\n/tool fetch url=\”http://dynamic.zoneedit.com/auth/dynamic.html\?host=dyndns.example.com\” user=ZEUser password=ZEPass keep-result=no” policy=read

Test the script by running it manually:

• /system script run zoneedit-dyndns

If it shows 2 lines of “status: finished”, then the script works properly.

Schedule the script to run regularly (in this case, every 10 minutes):

• /system scheduler add name=”zoneedit-dyndns” interval=10m on-event=”/system script run zoneedit-dyndns” policy=read,test

Why does it require 2 “fetch” commands to update?  I think there is a bug in ZoneEdit’s Dynamic DNS updater, so it needs to be forced. The new dynamic DNS change entry has to be significantly different from the previous dynamic DNS entry before the ZoneEdit backend would really update it.

Thanks, ZoneEdit!

Once you have installed the modified MidpSSH, there is a very good chance that your mobile operator blocks outgoing TCP port 22 on your BIS plan. You need to reconfigure your SSH server to listen on another port (port 2222 works for me).

In case you wonder how to specify the custom port (since there is no specific port field), specify the port in the Host field, e.g. 127.0.0.1:2222.

Hope this helps!

I was excited to see some minimal OS templates on the web Control Panel. I have a Debian 4.0 UK VPS. This time I choose Ubuntu 6.06, because there are lots of Ubuntu repository mirrors in Indonesia.

Once I rebuilt the VPS with Ubuntu template, the VPS cannot be instantly ssh’d into. sshd fails to start because  udev is installed and we need to remove that. Quickly remove udev by typing the following on Command Center: apt-get -y remove udev

Once it’s removed, reboot the VPS. Voila! You should be able to login using SSH now.

No need to do mknod /dev/random c 1 8, mknod /dev/urandom c 1 9, /sbin/MAKEDEV tty, /sbin/MAKEDEV ttyp, nor /sbin/MAKEDEV pts.

References:
http://prajizworld.com/?p=5

Initially I thought this was a small issue but eventually after the system boots up, I couldn’t restart the system with reboot, shutdown, nor init 6. It would stuck/freeze/hang at the “Uptime: …” line and before the “Rebooting..” line. I tried with 2 other barebones thinking that it is hardware issue, I got same results though. Clearly this is a bug in FreeBSD 6.3-RELEASE’s kernel.

I tried installing FreeBSD 6.4-RELEASE (32-bit) and it restarted properly. I was going to update the system to 6.3-STABLE — the server has to run 6.3, as 6.4 is not acceptable yet due to software compatibility issues — to see if the issue has been addressed in the -STABLE branch, but when I tried recompiling the kernel with PAE (in addition to SMP) support (still using -RELEASE kernel source tree), the reboot problem disappeared. YAY! I got it the fix by accident!

I’m not sure what is wrong since similar reboot problem seems to be popping around randomly since FreeBSD 5.X (after doing some Google searches). Browsing the PR database of FreeBSD didn’t help much either. Maybe if you know exactly what is wrong, you can share it here to help others with similar problem.

/usr/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in envdir.o
/lib64/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [envdir] Error 1

If there is a conf-cc file, then add “–include /path/to/errno.h” to the gcc line. Normally the file is at /usr/include/errno.h.

References:
http://cr.yp.to/docs/unixport.html#errno

Out of the few advantages ext4 has over ext3, there is one feature which is very useful to ensure integrity of the file system, journal checksumming.

Quoting Wikipedia’s article on ext3:

Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.

Consider the following scenario: If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or unrecoverable crash should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the “winners” (transactions with a commit block, including the invalid transaction above which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. There is a test program available to trigger the problematic behavior. If checksums had been used, where the blocks of the “fake winner” transaction were tagged with a mutual checksum, the file system could have known better and not replayed the corrupt data onto the disk. Journal checksumming has been added to EXT4.

The ext3 barrier option is not enabled by default on almost all popular Linux distributions, and thus most distributions are at risk. In addition, filesystems going through the device mapper interface (including software RAID and LVM implementations) may not support barriers, and will issue a warning if that mount option is used. There are also some disks that do not properly implement the write cache flushing extension necessary for barriers to work, which causes a similar warning. In these situations, where barriers are not supported or practical, reliable write ordering is possible by turning off the disk’s write cache and using the data=journal mount option.

ext3 apparently has a feature called write barriers which can help maintain integrity without journal checksumming, but there is a conflicting report over its performance impact.

Quoted from Andreas Dilger in a mail to ext3-users mailing list in May 2007:

Ideally, the jbd layer could be notified when the transaction blocks are flushed from device cache before writing the commit block, but the current linux mechanism to do this (write barriers) sucks perforance-wise (it sent throughput from 180MB/s to 7MB/s when enabled in our test systems). It was better to just turn off write cache entirely than to use barriers.

contradicts this post made by specialj in October 2008:

Well, I think I see where ext3 gets its reputation for slow deletes. With the write cache off the delete performance is terrible, nearly 70% lower. It’s clear that enabling write barriers does something as the numbers are lower on a number of items (though not all). However it’s clear that write barriers is minor loss of performance compared to turning the write cache off. I think this leads me to consider how many servers I can run with just ext3 and md raid1 so as to keep the write cache enabled and the filesystem safe. I’ll have to weigh the performance gains against the benefits of using LVM (especially snapshots) and dm-crypt (which might have limited benefits on a server anyway).

Maybe some improvements had been done at the write barriers feature of ext3 since Andreas Dilger’s post, but I couldn’t find anything on Google about it. I couldn’t even find a website which has proper documentation on ext3′s write barriers. At least now I have specialj’s Bonnie++ test results from 2 months ago and it’s good enough to convince me enabling write barriers on all of my servers which run md raid1.

Thanks, specialj!

References:
http://hightechsorcery.com/2008/10/evaluating-performance-ext3-using-write-barriers-and-write-caching
http://hightechsorcery.com/2008/06/linux-write-barriers-write-caching-lvm-and-filesystems
http://archives.free.net.ph/message/20070518.190346.7a4c0f9f.en.html

Once the installation was complete, it rebooted and I found a painfully slow newly-installed CentOS system. The keyboard response was slow as if I were connected to a remote server with 1 second latency. I wasn’t happy because this is a quad-core processor server with acceptable amount of RAM. When I looked at /proc/mdstat to see how the software RAID is doing, I noticed that the sync speed is only around 1000KB/s. I tried looking for solutions on Google and found this and this. The solution I got didn’t help increase the sync speed, nor the slow response I was getting typing on the console or remotely.

I then somehow managed to find another possible solution. I can’t remember how I finally got this solution (thanks to nixCraft/CyberCiti). I didn’t notice that the hard drives were actually detected as hdX (IDE/PATA) instead of sdX (SATA). Now this makes sense because PATA is much slower than SATA. It turned out to be an issue with the hardware detection process. Somehow CentOS detected the HDDs and used PATA driver instead of SATA driver, so the devices were named hdX and treated as PATA hence the slow sync speed. I made the BIOS changes as mentioned in the solution and attempted another install, it was REALLY fast this time and the software RAID 1 sync speed was over 70000KB/s.

References:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=16178
http://lists.centos.org/pipermail/centos/2005-February/002068.html
http://www.ducea.com/2006/06/25/increase-the-speed-of-linux-software-raid-reconstruction/
http://www.cyberciti.biz/faq/linux-sata-drive-displayed-as-devhda/
http://www.nodeofcrash.com/?p=57