/etc insider

since 1999 (and still editing)

OpenBSD’s PF for Mac OS X is mostly outdated, broken, rotten

| Comments

Being a Mac OS X user (too, not solely) for a while I know of Apple developers’ attempts to bring in some packet firewall (I guess they already had “Socket (level) firewall) into OS X. They’ve tried FreeBSD’s ipfw and threw it out later, although you can see its reamins are still in system, even El Capitan:

sysctl net.inet.ip.fw

and they’re trying with PF now. PF itself has rather harsh way of evolving. First of all, term “forking” would be very much appropriate here. PF for FreeBSD and OpenBSD’s PF are pretty much forks. FreeBSD 10.2 uses PF from OpenBSD 4.5. Their ways are greatly diverged. If being asked which one I’d prefer I’d rather go with OpenBSD’s, buuut, I admit it became more complex than anybody would expect in the beginning. NAT/routing syntax, for e. g., is pretty much different between them.

Well, back again to Mac OS X. I don’t know which OpenBSD version they have choosen (this is very interesting question), but I can assure you that both in Yosemite and El Capitan it’s rather “outdated, broken, rotten”.

You should realize that it contains bugs that were fixed long time ago in upstream and it lacks of some features too, even not that modern. A few things to mention:

  • TCP modulate state isn’t working, don’t waste your time with trying:
 % cat -n pf-modulate.conf 
     1    pass all
     2    pass out on lo0 proto tcp from any to any port 22 modulate state
 % sudo pfctl -ef pf-modulate.conf
 % nc -w 1 22        
 % nc -w 1 22
 % head -n1 pf-modulate.conf | sudo pfctl -f -
 % sudo pfctl -s r 2>/dev/null
pass all flags S/SA keep state
 % nc -w 1 22                       
 % nc -w 1 22
  • Logging worked really strange. I’d say that it worked rather sticky, w/o ability to unset logging for specific rules sometimes (circumstances are unclear), although I don’t have any confirmation on hands now. I’ll update it if I find again eventually.

  • route-to and nat (together) won’t give you the result you expect. It works as expected in FreeBSD 10.2 (and may be 10.1), although it takes you to a quiz way. ;) It works in OpenBSD although as I said earlier syntax there’s changed significantly.

  • (self) and co. – the manual page says: “Surrounding the interface name (and optional modifiers) in parentheses changes this behaviour.” It simply doesn’t work. You’d have to pfctl -f your ruleset file.

So, what’s in the rest? – Don’t expect much from PF on Mac OS X. It works generally. Buuuut…

Ough, and I was able to crash El Capitan at least 2 or 3 times when experimenting with “nat route-to”.

ZRAM and bcache as swap storage

| Comments

Use of ZRAM for swap is not new approach. In case you missed it, ZRAM kernel module makes “virtual” block device that is in fact RAM backed storage – like RAM drive, but with one important difference: the data in that storage is compressed, so, depending of the nature of those data, memory consumption would be less than of usual RAM drive. Say, we have 6 GB RAM available and then we allow to allocate up to 1 GB of physical memory for ZRAM drive. In general we can expect factor 2 compression (and even more for text data), so, it means we loose 1 GB, but get 2 GB in return.

Our system would have now only 5 GB RAM, but plus 2 GB of swap disk on very fast storage. I used this setup quite soon after ZRAM was brought into vanilla kernel.

Since RAM disks are very fast, this might be true improvement – unless you get constant swapping, that would be noticeable anyways, in despite of having lightning fast RAM storage. But there’re no wonders – you can’t just have all for nothing, even if you engineered it. If you still have high memory pressure in your system, it’s time to go get more RAM in shop, indeed.

One thing did always bothered me with it though – I’d prefer ZRAM to have real (hard or SSD) disk storage attached so it could place inactive (less recently used) pages there. RAM is precious resource and having it filled with anything that system wouldn’t need soon is a real waste, even if it’s compressed.

Should I say that as soon as bcache (and other similar projects) evolved, I tried making that combination. Alas, a few of them just caused kernel panic, and as to bcache – it refused to make a pair with ZRAM drive at all. Some time after I found a solution, although, and here I’m going to present it to you.

So, let’s begin – first of all you’d need to get bcache. The module itself goes with vanilla kernel since version XXX, but we’d need bcache-tools as well in order to interact with the module. I’d assume that you have it downloaded into /usr/local/src/bcache-tools and compiled it there.

kexec to solve slow reboot your Linux server

| Comments

Days when boys showed off with theirs UNIX systems uptime are mostly gone. Currently, if you don’t reboot your system it means only one of two: either you don’t get fixes for kernel issues or you have kernel live patching.

Meanwhile typical SOHO boxes have quite vivid BIOSes, “production grade” boxes are not fast usually – you can easily spend a few minutes (or even more) awaiting all those procedures to finish. In some scenarios, alas, you’re not the only person who would wait for services to come back. With kexec you can eliminate most of the delays related to BIOS and firmware activity. Having tried kernel preloading with kexec might look like this:

kexec -l vmlinuz-2.6.32-openvz-042stab112.15-amd64 --initrd=initrd.img-2.6.32-openvz-042stab112.15-amd64 --reuse-cmdline

To me this reduced reboot to alive network time from 55 seconds down to 12. Your mileage may be even more impressive.

BFS for Mac OS X does not exist, so what?

| Comments

When Con Kolivas came with his own task scheduler for Linux (long before he came up with Brain Fuck Scheduler name), one of the proposal to Linus-and-co to consider was modular design so that user would have free choice of using one or another scheduler w/o need to patch-compile kernel. Probably it would even support on-line switching as, for e. g., disk’ schedulers do.

Alas, they invented shitty excuse that it’s better to have only one scheduler due to users can have another point of misconfiguration for their Linux running systems. Sounds as an absolute bull-shit and of course you can see just another example of why Linus can be considered a jerk (he wouldn’t care, don’t worry).

I had to have remembered this story as soon as I noticed Mac OS X kernel’s had an entry in its sysctls named kern.sched. “Whoa!”, I thought, “does it really support changing the scheduler on fly?” – in fact as it turned out, it doesn’t. But, at least, you can specify it at boot time. So, as I can tell you of now, there’re traditional, multiq and dualq options available. By default, my system used multiq, out of curiosity, I tried sudo nvram boot-args='-v sched=dualq' and it switched. Of course it did a huge boost in performance I didn’t notice a thing except the sysctl’s output changed. But it’s good to know that with Mac OS X you have an option and who knows may be someday, there would be option bfs too, huh?

Don’t grep ps by PID

| Comments

Watching some video tutorials I notice sometimes tutors type in stuff similar to this way too often:

ps -e | grep 42

This is being done for finding if process with PID 42 is still being run, for e. g.. What’s really should be used instead is ps alone (not to mention fgrep instead of grep):

ps 42.

If you want to remember it, you’d better give it a try now: ps 1 – you always can expect to have init process running and by convention it’s PID 1. As can be seen (and remembered) ps alone can give you info about specified PID, and this is quite portable feature, it works the same way on Linux, FreeBSD, Mac OS X and you-name-it.

OTOH, grep still makes sense when searching by name indeed. It has own drawbacks, namely finding itself too but that’s something you can workaround with a clever old trick – just use square brackets:

ps -e | grep 'syslo[g]'

instead of ps -e | grep syslog

Text syslo[ doesn’t match pattern syslo[g]. Of course if you were looking for something with grep in name, this trick won’t do and this could be the time to use pgrep instead.

Dealing with tight RAM on Linux

| Comments

Well, as the title suggest you can do something to have smoother experience when you just can’t plug more RAM into your laptop or desktop.

From the ground up it’s the choice of the distro and architecture: prefer x86, not x86_64. If you had tried x86 and x86_64 versions of your distro on same laptop with 2 GB you already know that advice. x86_64 is superior technology, no doubts, but alas its drawback binaries are noticeable bigger and their memory apetite is bigger too.

Use swap, so anything that can be swapped out due to inactivity, would be swapped out. Don’t use big swap partition with memory overcommit setting. Swap is good for RAM saving, but disk thrashing due to swap can last way too long so you lose your nerve and may even come up with a vain desire to turn off the swap altogether.

Optimize things that can’t be swapped out. Some kernel sub-systems can be taught to be less memory-wasting, for e. g.:


being given as kernel’s parameter would save some RAM indeed.

Try using pre-swap compressing in RAM:

zswap.enabled=1 zswap.compressor=deflate

ZSWAP allocates some pre-disk-swap buffer in RAM (its size can be configured too), and to make this RAM-effective its content should be compressed, otherwise there’s no point, right? The better it’s compressed, the more sense there’s to “waste” RAM for that buffer, so that’s why I recommend using deflate compression method. Generally, processors became way too fast for long time and if you have any opportunity to trade CPU cycles for cutting down disk activity, go for it! No need for LZO or LZ4 if you really want to hit disks less often.

Use UltraKSM. People who read this blog should be already aware of that. It’s a pity uKSM doesn’t get its way into vanilla kernel yet, but you know where to get it.

Use alternative memory allocators system-wide. For e. g., you can try jemalloc which is known for its great memory fragmentation durability that makes sense over the time. You may have noticed that over the time your system can become more and more sluggish. Should you only re-start your session and things can be faster again. With jemalloc you can find those restarts are needed less frequently.

i386 version of 4.1.9 with BFS, BFQ and UltraKSM

| Comments

One thing suddenly jumped into my mind – targeting all those enhanced features of kernel for modern hardware makes less and less sense. Really, while, say uKSM makes you’re happier with saved memory (although if you never hit swap it’s also of no use, right) using BFQ or BFS isn’t so demanded. CPUs are pretty fast now, as to disks, most of those who needs speed did switch to SSD long ago too. Yeah, in general you can feel something good for using something better, but this is not that much-much more better. Just better, a little bit. And as you use more and more powerful hardware the gain from those enhancements is going down until it’s undistingushable. OTOH, if you’re old hardware owner that still of use. Here it is – version for x86.

Please note it needs at least Pentium 4.

4.1.4 with UltraKSM, BFQ and BFS built and being tested

| Comments

UltraKSM’s patch from 4.0 have had a minor conflict that didn’t take much time to be resolved. Currently I’m testing it on own laptop:

% uname -r

and, if a few days of usual work-load would indicate no issues, .deb packages would come soon.

P.S. I’m really curious of how many of you are using these builts, so “liking” and “sharing” would show your appreciation.

TIL: PHP best practice is not using matching closing php tag at EOF

| Comments

Today I learnt: it’s considered best practice to not close <?php tag with corresponding ?> at End-of-File! – Did you know it?

Looking at WordPress sources I noticed (specially it was clearly seen for “silence is golden” files) that there’s no closing php-tag. I was curious enough to go to online sources which they still have in SVN (I went to Github first, but links were kinda broken so I started studying it from https://core.trac.wordpress.org/ ) and found huge developers conversation (or arguing may be more precise to say) in regards of this subject.

It turned out then that official PHP manual explicitly states it:

Note: The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include or require, so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

</?php not>