Monthly Archives: May 2011

AR9287 update

I finally gave in and whacked a FreeBSD-HEAD snapshot on my EEEPC so I can test the ath 802.11n code out with the various mini-PCIe NICs I have.

ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 on pci1
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9287 mac 384.2 RF5133 phy 15.15

.. and

wlan0: flags=8843 metric 0 mtu 1500
ether b4:82:fe:33:95:53
inet 10.61.8.27 netmask 0xffffff00 broadcast 10.61.8.255
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid CACHEBOY_RS channel 1 (2412 MHz 11g ht/40+) bssid 00:1b:b1:58:f6:f0
regdomain ROW country AU indoor ecm authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 bmiss 7
scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7
roam:rate 64 protmode CTS -ampdu ampdulimit 32k ampdudensity 8 -amsdu
shortgi wme burst roaming MANUAL

(Yes, there's no TX aggregation support for now so I've disabled ampdu.)

And:

ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
00:1b:b1:58:f6:f0 1 1 216M 24.5 0 30271 30064 EPS AQEHTRS RSN HTCAP WPA WME

It's happily sitting at MCS12 from my bedroom (which is what I expect given the noise on the 2.4ghz band where I live.)

AR9287 update

I finally gave in and whacked a FreeBSD-HEAD snapshot on my EEEPC so I can test the ath 802.11n code out with the various mini-PCIe NICs I have.ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 on pci1ath0: [HT] enabling HT modesath0: [HT] 2 RX streams; 2 TX streamsath0: AR9287 mac 384.2 RF5133 phy 15.15.. andwlan0: flags=8843 metric 0 mtu 1500 ether b4:82:fe:33:95:53 inet 10.61.8.27 netmask 0xffffff00 broadcast 10.61.8.255 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid CACHEBOY_RS channel 1 (2412 MHz 11g ht/40+) bssid 00:1b:b1:58:f6:f0 regdomain ROW country AU indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 64 protmode CTS -ampdu ampdulimit 32k ampdudensity 8 -amsdu shortgi wme burst roaming MANUAL(Yes, there's no TX aggregation support for now so I've disabled ampdu.)And:ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG00:1b:b1:58:f6:f0 1 1 216M 24.5 0 30271 30064 EPS AQEHTRS RSN HTCAP WPA WMEIt's happily sitting at MCS12 from my bedroom (which is what I expect given the noise on the 2.4ghz band where I live.)

EuroBSDCon 2011

EuroBSDCon 2011 (http://2011.eurobsdcon.org/), The Netherlands 6 - 9 October, 2011. EuroBSDCon is the annual European technical conference for users and developers on BSD based systems. The 10th European BSD Conference will take place in the Netherlands in October, 2011 and include a technical track, tutorials, and FreeBSD developer summit. Topics of interest to the conference include, but are not limited to applications, architecture, implementation, performance and security of BSD based operating systems, as well as topics concerning the economic or organizational aspects of BSD use.

BSDCan Trip Report: Daichi Goto

The FreeBSD Foundation recently provided a travel grant to Daichi Goto to attend BSDCan and the FreeBSD Developer Summit. He has provided the following trip report:

What have you accomplished by attending this conference?

I have written thirteen BSDCan 2011 related articles for the "FreeBSD Daily Topics" section of gihyo.jp. The articles describe BHyVe, virtualization, FreeBSD on Amazon EC2, BSDInstall, PKGng, tool-chains, PCI Express hot-plug, Chromium, UFS2/SUJ, GEOM performance, and FreeBSD vendors. Articles will be posted one per day and the complete list can be found here.

I will also write about the new features of FreeBSD 9 and 10 for the MYCOM Journal and about IPv6 and HAST for @IT. Both are major Japanese IT news sites and the articles will be written in Japanese.

What did you learn by attending BSDCan and the DevSummit?

Many many things. BSD Hypervisor BHyVE and virtualization situation are very hot. The FreeBSD DevSummit is a great opportunity to get fresh FreeBSD news and developers thinking. I was able to travel with my mentor, Hiroki Sato, from whom I have learned many things. I also learned new things from the IPv6 tutorial attendees and other FreeBSD developers.

Thanks again to the Foundation for your support!

BSDCan Trip Report: Daichi Goto

The FreeBSD Foundation recently provided a travel grant to Daichi Goto to attend BSDCan and the FreeBSD Developer Summit. He has provided the following trip report:

What have you accomplished by attending this conference?

I have written thirteen BSDCan 2011 related articles for the "FreeBSD Daily Topics" section of gihyo.jp. The articles describe BHyVe, virtualization, FreeBSD on Amazon EC2, BSDInstall, PKGng, tool-chains, PCI Express hot-plug, Chromium, UFS2/SUJ, GEOM performance, and FreeBSD vendors. Articles will be posted one per day and the complete list can be found here.

I will also write about the new features of FreeBSD 9 and 10 for the MYCOM Journal and about IPv6 and HAST for @IT. Both are major Japanese IT news sites and the articles will be written in Japanese.

What did you learn by attending BSDCan and the DevSummit?

Many many things. BSD Hypervisor BHyVE and virtualization situation are very hot. The FreeBSD DevSummit is a great opportunity to get fresh FreeBSD news and developers thinking. I was able to travel with my mentor, Hiroki Sato, from whom I have learned many things. I also learned new things from the IPv6 tutorial attendees and other FreeBSD developers.

Thanks again to the Foundation for your support!

FreeBSD portmgr thank you to the FreeBSD Foundation

The FreeBSD Ports Management Team wrote a thank you note to the Foundation for providing travel grants to several developers who therefore were able to attend the very successful Ports Working Group session.

We would like to publicly thank the FreeBSD Foundation for granting Baptiste Daroussin and Julien Laffaye a travel grant to travel to BSDCan 2011 for the Ports and Packages Working Group held at in Ottawa last week. The working group itself was a huge success and a number of improvements with regard to automated binary package creation and distribution to ease upgrade procedures for our users were discussed and will hopefully be implemented over the next few months.

None of these improvements, however, would be possible without a long overdue rewrite of the package tools provided by FreeBSD. Over last few years, a number of attempts were made to enhance the current tools, but none have been as all-compassing as the PKGNG project by Baptiste and Julien. The presentation given by Baptiste at the packages summit and summariszed at the DevSummit track of BSDCan showed a comprehensive new tool that can completely replace the current tools, and provide a clear migration path from the old to the new tool. It also provides a large number of new features while keeping the old ones and is a lot more flexible to be able to add more features later. As you may have heard, Baptiste has also joined the ports management team as a result of his efforts.

Thanks again to the Foundation for sponsoring Baptiste, Julien, Simon Nielsen (Deputy Security Officer) and Thomas Abthorpe (Ports Management Team) who all were instrumental into making the ports working group such a success.

FreeBSD portmgr thank you to the FreeBSD Foundation

The FreeBSD Ports Management Team wrote a thank you note to the Foundation for providing travel grants to several developers who therefore were able to attend the very successful Ports Working Group session.

We would like to publicly thank the FreeBSD Foundation for granting Baptiste Daroussin and Julien Laffaye a travel grant to travel to BSDCan 2011 for the Ports and Packages Working Group held at in Ottawa last week. The working group itself was a huge success and a number of improvements with regard to automated binary package creation and distribution to ease upgrade procedures for our users were discussed and will hopefully be implemented over the next few months.

None of these improvements, however, would be possible without a long overdue rewrite of the package tools provided by FreeBSD. Over last few years, a number of attempts were made to enhance the current tools, but none have been as all-compassing as the PKGNG project by Baptiste and Julien. The presentation given by Baptiste at the packages summit and summariszed at the DevSummit track of BSDCan showed a comprehensive new tool that can completely replace the current tools, and provide a clear migration path from the old to the new tool. It also provides a large number of new features while keeping the old ones and is a lot more flexible to be able to add more features later. As you may have heard, Baptiste has also joined the ports management team as a result of his efforts.

Thanks again to the Foundation for sponsoring Baptiste, Julien, Simon Nielsen (Deputy Security Officer) and Thomas Abthorpe (Ports Management Team) who all were instrumental into making the ports working group such a success.

FreeBSD portmgr thank you to the FreeBSD Foundation

We would like to publicly thank the FreeBSD Foundation for granting Baptiste Daroussin and Julien Laffaye a travel grant to travel to BSDCan 2011 for the Ports and Packages Working Group held at in Ottawa last week.  The working group itself was a huge success and a number of improvements with regard to automated binary package creation and distribution to ease upgrade procedures for our users were discussed and will hopefully be implemented over the next few months.

None of these improvements, however, would be possible without a long overdue rewrite of the package tools provided by FreeBSD.  Over last few years, a number of attempts were made to enhance the current tools, but none have been as all-compassing as the PKGNG project by Baptiste and Julien.  The presentation given by Baptiste at the packages summit and summariszed at the DevSummit track of BSDCan showed a comprehensive new tool that can completely replace the current tools, and provide a clear migration path from the old to the new tool.  It also provides a large number of new features while keeping the old ones and is a lot more flexible to be able to add more features later.  As you may have heard, Baptiste has also joined the ports management team as a result of his efforts.

Thanks again to the Foundation for sponsoring Baptiste, Julien, Simon Nielsen (Deputy Security Officer) and Thomas Abthorpe (Ports Management Team) who all were instrumental into making the ports working group such a success.

 

Thomas
on behalf of portmgr@

libcxxrt C++ Runtime Now Available Under BSD License

The FreeBSD Foundation and the NetBSD Foundation announced today that they have acquired a non-exclusive copyright license to the libcxxrt C++ runtime software from PathScale, a leader in high performance Fortran, C and C++ compiler products for AMD64, Intel64 and MIPS. The press release, available from the FreeBSD Foundation, Pathscale, and PRWeb websites, is as follows:

The FreeBSD Foundation and the NetBSD Foundation announced today that they have acquired a non-exclusive copyright license to the libcxxrt C++ runtime software from PathScale, a leader in high performance Fortran, C, and C++ compiler products for AMD64, Intel64, and MIPS. This software is an implementation of the C++ Application Binary Interface originally developed for Itanium and now used for the x86 family by BSD operating systems. Libcxxrt will be available under the 2-clause BSD license.

This implementation is a full replacement for the GNU libsupc++ library for platforms that use the Itanium C++ ABI, including i386 and x86-64, and will replace portions of the C++ stack previously only available under the GPL. It provides implementations of the dynamic features of C++, including dynamic casting, exception handling, and thread-safe static initializers, and will continue the gradual replacement of GNU toolchain and runtime components, furthering the aim of a purely BSD-licensed system.

"This work complements other work done in the community and is a further step in letting us adopt alternative toolchains in FreeBSD," said Robert Watson, a FreeBSD committer and Director at the FreeBSD Foundation.

"There are already a number of STL implementations with other licenses, but libcxxrt is the missing link for a BSD licensed C++ compiler and the C++ runtime," said NetBSD developer Joerg Sonnenberger.

"It's great to work with the BSD community and help provide these core parts of the toolchain," said Christopher Bergström, CTO at PathScale. "This is a first step to PathScale offering first class support for both NetBSD and FreeBSD."

About The FreeBSD Foundation

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project and community. The Foundation gratefully accepts donations from individuals and businesses, using them to fund and manage projects, sponsor FreeBSD events, Developer Summits and provide travel grants to FreeBSD developers. In addition, the Foundation represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. The FreeBSD Foundation is entirely supported by donations. More information about The FreeBSD Foundation is available on the web.

About The NetBSD Foundation

The NetBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the NetBSD Project and community. Under its education and research mandate, it supports development of the NetBSD operating system which supports over fifty different computer architectures from a single, unified set of kernel and userland source files. The NetBSD codebase is used by commercial embedded developers, educational institutions, and individual end-users. Through donations received from individuals and corporations the Foundation is able to fund substantial work undertaken by developers. More information about The NetBSD Foundation is available on the web.

About PathScale

PathScale Inc. has developed industry leading high performance Fortran, C and C++ compiler products for AMD64, Intel® 64, MIPS processors and provides support to users desiring the highest level of performance from their applications. The PathScale EKOPath Compiler Suite has the world's most advanced optimization infrastructure and can fully exploit the potentials of many-core architectures. The company’s goal is to deliver robust and high performance compilers tailored to clustered, GPGPU and multi-core computing environments. More information about PathScale is available on the web.

libcxxrt C++ Runtime Now Available Under BSD License

The FreeBSD Foundation and the NetBSD Foundation announced today that they have acquired a non-exclusive copyright license to the libcxxrt C++ runtime software from PathScale, a leader in high performance Fortran, C and C++ compiler products for AMD64, Intel64 and MIPS. The press release, available from the FreeBSD Foundation, Pathscale, and PRWeb websites, is as follows:

The FreeBSD Foundation and the NetBSD Foundation announced today that they have acquired a non-exclusive copyright license to the libcxxrt C++ runtime software from PathScale, a leader in high performance Fortran, C, and C++ compiler products for AMD64, Intel64, and MIPS. This software is an implementation of the C++ Application Binary Interface originally developed for Itanium and now used for the x86 family by BSD operating systems. Libcxxrt will be available under the 2-clause BSD license.

This implementation is a full replacement for the GNU libsupc++ library for platforms that use the Itanium C++ ABI, including i386 and x86-64, and will replace portions of the C++ stack previously only available under the GPL. It provides implementations of the dynamic features of C++, including dynamic casting, exception handling, and thread-safe static initializers, and will continue the gradual replacement of GNU toolchain and runtime components, furthering the aim of a purely BSD-licensed system.

"This work complements other work done in the community and is a further step in letting us adopt alternative toolchains in FreeBSD," said Robert Watson, a FreeBSD committer and Director at the FreeBSD Foundation.

"There are already a number of STL implementations with other licenses, but libcxxrt is the missing link for a BSD licensed C++ compiler and the C++ runtime," said NetBSD developer Joerg Sonnenberger.

"It's great to work with the BSD community and help provide these core parts of the toolchain," said Christopher Bergström, CTO at PathScale. "This is a first step to PathScale offering first class support for both NetBSD and FreeBSD."

About The FreeBSD Foundation

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project and community. The Foundation gratefully accepts donations from individuals and businesses, using them to fund and manage projects, sponsor FreeBSD events, Developer Summits and provide travel grants to FreeBSD developers. In addition, the Foundation represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. The FreeBSD Foundation is entirely supported by donations. More information about The FreeBSD Foundation is available on the web.

About The NetBSD Foundation

The NetBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting the NetBSD Project and community. Under its education and research mandate, it supports development of the NetBSD operating system which supports over fifty different computer architectures from a single, unified set of kernel and userland source files. The NetBSD codebase is used by commercial embedded developers, educational institutions, and individual end-users. Through donations received from individuals and corporations the Foundation is able to fund substantial work undertaken by developers. More information about The NetBSD Foundation is available on the web.

About PathScale

PathScale Inc. has developed industry leading high performance Fortran, C and C++ compiler products for AMD64, Intel® 64, MIPS processors and provides support to users desiring the highest level of performance from their applications. The PathScale EKOPath Compiler Suite has the world's most advanced optimization infrastructure and can fully exploit the potentials of many-core architectures. The company’s goal is to deliver robust and high performance compilers tailored to clustered, GPGPU and multi-core computing environments. More information about PathScale is available on the web.

What keramida said… » FreeBSD 2011-05-20 18:11:15

I found out how to concatenate the parts of a video to a single file with MPlayer. It’s relatively easy, so this is just a mini-post to save it for posterity:

$ cat video_part1.avi video_part2.avi ... > temp.avi
$ mencoder -forceidx -oac copy -ovc copy \
    temp.avi -o final.avi && \
    rm temp.avi

Filed under: Computers, Free software, FreeBSD, Linux, Open source, Software Tagged: Computers, Free software, FreeBSD, hellug, Linux, Open source, Software

So long HP Blade Cluster and thanks for all the packages

After many years of faithful service, today the FreeBSD Ports Management Team decided to decommission the HP Blade Cluster. When the 20-node BladeSystem was donated to the FreeBSD Foundation, by Hewlett-Packard back in 2005, it tripled the speed of the i386 package building process. Today, and several hardware generations later however, it is no longer profitable to keep the system running inside the cluster. The portmgr team has been very pleased with the system, especially the built-in out-of-band power management- and console system. The system has also proved to be very reliable; even with continuous high workloads for so many years, the only hardware failures we experienced were some of the disks. The i386 package cluster now consists of 5 Xeon-based servers hosted at ISC until the new clusters are fully online.

We again wish to thank HP for their generous donation and Yahoo! for hosting it in one of their datacenter.

How I setup a Jail-Host

Everyone has his own way of setting up a machine to serve as a host of multiple jails. Here is my way, YMMV.

Initial FreeBSD install

I use several harddisks in a Software–RAID setup. It does not matter much if you set them up with one big partition or with several partitions, feel free to follow your preferences here. My way of partitioning the harddisks is described in a previous post. That post only shows the commands to split the harddisks into two partitions and use ZFS for the rootfs. The commands to initialize the ZFS data partition are not described, but you should be able to figure it out yourself (and you can decide on your own what kind of RAID level you want to use). For this FS I set atime, exec and setuid to off in the ZFS options.

On the ZFS data partition I create a new dataset for the system. For this dataset I set atime, exec and setuid to off in the ZFS options. Inside this dataset I create datasets for /home, /usr/compat, /usr/local, /usr/obj, /usr/ports/, /usr/src, /usr/sup and /var/ports. There are two ways of doing this. One way is to set the ZFS mountpoint. The way I prefer is to set relative symlinks to it, e.g. “cd /usr; ln –s ../data/system/usr_obj obj�. I do this because this way I can temporary import the pool on another machine (e.g. my desktop, if the need arises) without fear to interfere with the system. The ZFS options are set as follows:

ZFS options for data/system/*

Dataset

Option

Value
data/system/homeexecon
data/system/usr_compatexecon
data/system/usr_compatsetuidon
data/system/usr_localexecon
data/system/usr_localsetuidon
data/system/usr_objexecon
data/system/usr_portsexecon
data/system/usr_portssetuidon
data/system/usr_srcexecon
data/system/usr_supsecondarycachenone
data/system/var_portsexecon

The exec option for home is not necessary if you keep separate datasets for each user. Normally I keep separate datasets for home directories, but Jail-Hosts should not have users (except the admins, but they should not keep data in their homes), so I just create a single home dataset. The setuid option for the usr_ports should not be necessary if you redirect the build directory of the ports to a different place (WRKDIRPREFIX in /etc/make.conf).

Installing ports

The ports I install by default are net/rsync, ports-mgmt/portaudit, ports-mgmt/portmaster, shells/zsh, sysutils/bsdstats, sysutils/ezjail, sysutils/smartmontools and sysutils/tmux.

Basic setup

In the crontab of root I setup a job to do a portsnap update once a day (I pick a random number between 0 and 59 for the minute, but keep a fixed hour). I also have http_proxy specified in /etc/profile, so that all machines in this network do not download everything from far away again and again, but can get the data from the local caching proxy. As a little watchdog I have a little @reboot rule in the crontab, which notifies me when a machine reboots:

@reboot grep "kernel boot file is" /var/log/messages | mail -s "`hostname` rebooted" root >/dev/null 2>&1

This does not replace a real monitoring solution, but in cases where real monitoring is overkill it provides a nice HEADS-UP (and shows you directly which kernel is loaded in case a non-default one is used).

Some default aliases I use everywhere are:

alias portmlist="portmaster -L | egrep -B1 '(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|Reason:|MOVED|deleted|exist|update' | grep -v '^--'"
alias portmclean="portmaster -t --clean-distfiles --clean-packages"
alias portmcheck="portmaster -y --check-depends"

Additional devfs rules for Jails

I have the need to give access to some specific devices in some jails. For this I need to setup a custom /etc/devfs.rules file. The files contains some ID numbers which need to be unique in the system. On a 9-current system the numbers one to four are already used (see /etc/defaults/devfs.rules). The next available number is obviously five then. First I present my devfs.rules entries, then I explain them:

[devfsrules_unhide_audio=5]
add path 'audio*' unhide
add path 'dsp*' unhide
add path midistat unhide
add path 'mixer*' unhide
add path 'music*' unhide
add path 'sequencer*' unhide
add path sndstat unhide
add path speaker unhide
[devfsrules_unhide_printers=6]
add path 'lpt*' unhide
add path 'ulpt*' unhide user 193 group 193
add path 'unlpt*' unhide user 193 group 193
[devfsrules_unhide_zfs=7]
add path zfs unhide
[devfsrules_jail_printserver=8]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_printers
add include $devfsrules_unhide_zfs
[devfsrules_jail_withzfs=9]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add include $devfsrules_unhide_zfs

The devfs_rules_unhide_XXX ones give access to specific devices, e.g. all the sound related devices or to local printers. The devfsrules_jail_XXX ones combine all the unhide rules for specific jail setups. Unfortunately the include directive is not recursive, so that we can not include the default devfsrules_jail profile and need to replicate its contents. The first three includes of each devfsrules_jail_XXX accomplish this. The unhide_zfs rule gives access to /dev/zfs, which is needed if you attach one or more ZFS datasets to a jail. I will explain how to use those profiles with ezjail in a follow-up post.

Jails setup

I use ezjail to manage jails, it is more comfortable than doing it by hand while at the same time allows me to do something by hand. My jails normally reside inside ZFS datasets, for this reason I have setup a special area (ZFS dataset data/jails) which is handled by ezjail.The corresponding ezjail.conf settings are:

ezjail_jaildir=/data/jails
ezjail_use_zfs="YES"
ezjail_jailzfs="data/jails"

I also disabled procfs and fdescfs in jails (but they can be enabled later for specific jails if necessary).

Unfortunately ezjail (as of v3.1) sets the mountpoint of a newly created dataset even if it is not necessary. For this reason I always issue a “zfs inherit mountpoint � after creating a jail. This simplifies the case where you want to move/rename a dataset and want to have the mountpoint automcatically follow the change.

The access flags of  /data/jails directory are 700, this prevents local users (there should be none, but better safe than sorry) to get access to files from users in jails with the same UID.

After the first create/update of the ezjail basejail the ZFS options of basejail (data/jails/basejail) and newjail (data/jails/newjail) need to be changed. For both exec and setuid should be changed to “on� The same needs to be done after creating a new jail for the new jail (before starting it).

The default ezjail flavour

In my default ezjail flavour I create some default user(s) with a basesystem-shell (via /data/jails/flavours/mydef/ezjail.flavour) before the package install, and change the shell to my preferred zsh afterwards (this is only valid if the jails are used only by in-house people, if you want to offer lightweight virtual machines to (unknown) customers, the default user(s) and shell(s) are obviously up to discussion). At the end I also run a “/usr/local/sbin/portmaster –y –check-depends� to make sure everything is in a sane state.

For the packages (/data/jails/flavours/mydef/pkg/) I add symlinks to the unversioned packages I want to install. I have the packages in a common (think about setting PACKAGES in make.conf and using PACKAGES/Latest/XYZ.tbz) directory (if they can be shared over various flavours), and they are unversioned so that I do not have to update the version number each time there is an update. The packages I install by default are bsdstats, portaudit, portmaster, zsh, tmux and all their dependencies.

In case you use jails to virtualize services and consolidate servers (e.g. DNS, HTTP, MySQL each in a separate jail) instead of providing lightweight virtual machines to (unknown) customers, there is also a benefit of sharing the distfiles and packages between jails on the same machine. To do this I create /data/jails/flavours/mydef/shared/ports/{distfiles,packages} which are then mounted via nullfs or NFS into all the jails from a common directory. This requires the following variables in /data/jails/flavours/mydef/etc/make.conf (I also keep the packages for different CPU types and compilers in the same subtree, if you do not care, just remove the “/${CC}/${CPUTYPE}� from the PACAKGES line):

DISTDIR=  /shared/ports/distfiles
PACKAGES= /shared/ports/packages/${CC}/${CPUTYPE}

New jails

A future post will cover how I setup new jails in such a setup and how I customize the start order of jails or use some non-default settings for the jail-startup.

Share

Dealing with pkg-config detection of FreeBSD’s base OpenSSL

Recently I spotted a software that uses pkg-config to find OpenSSL on the system. This way doesn't work on FreeBSD: it does have OpenSSL in base system, but it doesn't supply '*.pc' file, unfortunately. So, when configure script tries to execute pkg-config openssl it fails, obviously.There were a number of solutions suggested for this problem on #bsdports like replacing 'pkg-config openssl' with 'pkg-config pkg-config', depending on openssl from ports etc, but the cleanest solution is to define libssl_LIBS and libssl_CFLAGS environment variables, as was suggested by bapt@. In port's Makefile it would look something like this:
USE_OPENSSL=yesCONFIGURE_ENV+=libssl_CFLAGS="-I${OPENSSLINC}" libssl_LIBS="-L${OPENSSLLIB} -lssl"
Yes, configure will not call pkg-config if we define these 'libssl_*' variables. While it looks quite simple, this issue took surprisingly a lot time to figure everything out. :(