FreeRADIUS packages for Debian

Although announced a bit more than a month ago on the FreeRADIUS-users list, I though I might mention the package repository that I maintain for FreeRADIUS on Debian: Welcome 1Labs Packages!

There you can find:

  • Point releases for Debian jessie and wheezy of 3.0
  • (Bi-)weekly snapshots for Debian jessie and wheezy of 3.0
  • (Bi-)weekly snapshots for Debian jessie for 3.1 (until 3.1 gets released)

This is a complementary service that Fajar Nugraha has been providing via an unofficial Ubuntu PPA for the community. A similar offer hasn’t existed yet for Debian (only a rather stale SuSE OBS depot). So this is where I’d like to complement the current gap for Debian for anyone insterested.

(… from my point of view and knowledge) As of early to mid 2016 Debian and its siblings including Ubuntu only ship FreeRADIUS 2.x, this release branch has been EoL-ed by the FreeRADIUS project. Citing the commit message right after 2.2.9 preparing for a future 2.2.10 release:

commit c69b7e0abdb69e821133bbe030749bb119466256
Author: Alan T. DeKok <removed>
Date:   Tue Oct 6 09:11:27 2015 -0400

    Bump for 2.2.10

    Which will only be released if there are catastrophic security
    bugs.  Everyone should upgrade to 3.0

This isn’t the only occurrence where FreeRADIUS main developers emphasize on upgrading to 3.0 since their focus has shifted on this stable branch and the upcoming 3.1/3.2. I’d like to point out that the first 3.0.0 release has been made in October 2013. Most Linux distributions and the BSDs ship FreeRADIUS 3.0 in some way (even the rather conservative RHEL 7!) but not Debian and any derived distribution who get source packages from Debian.

As of now a bug report 797181 exists in Debian about FreeRADIUS 3, however in Alan’s DeKok’s own words:

The Debian maintainer seems to have disappeared, and is unresponsive.  
We need a new Debian maintainer, but the process isn't trivial, and no one has stepped forward.

(freeradius-users from Feb 26 2016)

Becoming a Debian maintainer isn’t such a quick thing and requires some efforts if you want to provide quality packages. This isn’t something I can afford my time on right now. However if nobody uses FreeRADIUS on Debian and Ubuntu, issues will go unseen and FreeRADIUS is going to get blamed for not running well on these distributions.

The FreeRADIUS source tree has been shipping with Debian packaging definitions for a long time but the exchange between up- and downstream hasn’t been so active. For some time the Debian packaging information in the FreeRADIUS source tree has been not in the best shape. Luckily this has changed for some months now and (IMHO) all deal-breaking issues have been resolved by a couple of helpful individuals (for example). With the snapshots build I hope to capture regressions more quickly and get a wider audience testing FreeRADIUS on Debian in order to make a future Debian maintainer’s life as smooth as possible. For what I can tell I’ve made rather positive experience with bug reports and small pull requests I have been involved with so far.

I can’t give any warranty that my package builds are bug free or are made with the best practises. For me it’s a learning experience and I have promised on the FreeRADIUS list to keep people informed if I have to or find a good reason to cease this effort. For the moment that’s what I can help with making the FreeRADIUS experience a bit more smooth and ease a future Debian maintainers’ effort.

March 14, 2016

Posted In: Uncategorized

Tags: ,

Leave a Comment

FreeRADIUS 2 to 3.0: Migration experience and nested LDAP groups

Since I migrated a FreeRADIUS 2.x server to 3.0 (finally!) I ran across some syntactical changes that have been in this release branch and sharing a small bit on the experience here on my blog.

Do I have redo my config from scratch?

The good news from my experience: No. If you haven’t totally messed up the default configurations a lot of snippets will still work with quick minor changes. Read twice, enter once and it’s likely going to fly quickly. As the project strongly recommends: You should really NOT reuse your FreeRADIUS 2.x configuration but start with the clean default configuration for v3, then modify them to the desired state. Unfortunately the experience of successfully adding back previous settings one by one I didn’t spot a difference that made my LDAP queries not work as I had expected them.

In FreeRADIUS 2.1.2 modules/ldap had the following default:

ldap {

[...]
   groupmembership_filter = "(|(&(objectClass=group)(member=%{control:Ldap-UserDn}))(&(objectClass=top)(uniquemember=%{control:Ldap-UserDn})))"
[...]

In FreeRADIUS 3.0.11 these options are split into into their own group section but the groupmembership_filter was also separated:

    group {
[...]
    #  Filter for group objects, should match all available
    #  group objects a user might be a member of.
    filter = '(objectClass=posixGroup)'

[...]
    #  Filter to find group objects a user is a member of.
    #  That is, group objects with attributes that
    #  identify members (the inverse of membership_attribute).
#   membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"

[...]

Now the filter for to identity group objects is short with filter and the membership_filter contains the query related to filtering the membership.

In my case the LDAP directory is an Active Directory where nested groups are not only allowed but I see them quite frequently used. Unfortunately standard queries won’t reveal nested memberships as this requires a specific query only supported by AD LDAP servers. Thankfully Nasser Heidari blogged how this could be achieved with FreeRADIUS 2 – and since most of my local changes worked readily with FreeRADIUS 3 I didn’t realize this had to be changed in a minor way.

In short in FreeRADIUS 2.x it was

groupmembership_filter = "(&(objectcategory=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))"

In FreeRADIUS 3.0 you want to split this to i.e.

filter = '(objectCategory=group)'
membership_filter = "(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn})"

Not a huge difference but if someone is rubbing his or her eyes during migration, this one seemed to be ok for me.

If you care about not running outdated software that isn’t really receiving much more love by the developers I can only encourage you moving to 3.0. Not only have there been a ton of performance improvements – there are definitely improvements in the configuration syntax I like as well.

January 5, 2016

Posted In: Uncategorized

Tags: , , ,

Leave a Comment

Unbricking a Sun Fire v210

These are notes on a system I made a couple of months ago but never got around polishing up, but finally kicked it out

At time of writing the Sun Fire v210, a entry-level UltraSPARC IIIi server from around 2003 was already dated, nonetheless I was able to get my hands on such a machine including another Sun box,  T1000. I just wanted to get my hands dirty on some non-x86 machines so that’s what I got myself pretty cheaply (being 1U they don’t take up too much space). Unfortunately I had to learn the hard way that some older Sun machines can be locked down pretty much so well that you can’t unbreak them without more advanced hackery that I currently am able off / want to invest my time — or with the help of similar/identical unlocked hardware.

The situation the box came to me:

  • The onboard system controller ALOM (service/management processor) started correctly but its password was unknown to me.
  • OpenBoot PROM (OBP) had both ‘security-mode=on’ and an active ‘security-password’, with the following result: Booting from anything else than the default (auto-boot set to the SCSI disk) required entering a “Firmware password” unknown as well. This exluded booting from the network or an optical drive. (for x86 folks like me: OpenBoot is roughly the equivalent to BIOS/UEFI but with some/lots more functionality)
  • With the disk inserted the box came up with a Solaris 9 that still seemed booting healthy, yet again: I didn’t have the a root password.
  • The machine came without a CD or DVD drive…

If you are in this situation lots of posts I found mentioned that you may require another Sun machine with a disk and a known root password that you can yank in and boot the locked system off to fix the issues. I didn’t have that luck (the T1000 is SAS based, the v210 U160 SCSI). Also: Mounting a UFS partition from a SPARC system on x86 may to fail because of different endianness. If it had been ZFS, well things would have been easier since it actually handles this for you. Also without any bootable Solarish’ OS I currently believe that you are out of luck with such a machine.

I’d also say that access to OpenBoot is the first key in order to get back into a more sane situation, ALOM is useful too but without OpenBoot you’re out. It is the key piece that enables you to boot the box from whatever source OpenBoot can boot from.

What didn’t work:

  • In contrast to x86 systems where you can most often short some jumpers or remove CMOS batteries most values in OpenBoot are stored in persistent storage areas, only the system clock is buffered by a CR2032 battery.
  • Modifying OpenBoot with enabled security-mode requires either knowing the firmware password or a bootable Solaris OS with access to command named eeprom(1M)
  • Without access to OpenBoot itself no jumper will reset the ALOM config like mentioned for the Sun Fire V100: On the V210 the equivalent jumper only reboots ALOM and that’s about it.
  • Without the ALOM’s password the sole way to modify its config is via the Solaris or illumos-only scadm(1M) command. A bootable OS is required for that. Unlike on the T1000: Hitting the ESC key in early start process of the ALOM startup doesn’t offer you the option to reset it to default settings and forget the passwords.

The magical System Configuration Card

While most LOM (LAN on motherboard) on x86 systems have their MAC-adresses burned in, on those Sun machines the MAC address is stored on a Smartcard called “System Configuration Card” (SCC) inserted at the front of the server. I came to learn that a box without this particular card would be pretty much useless as you can’t use the onboard NICs it. Also lots of other values of OpenBoot are stored on the SCC, including the (bloody!) firmware password.

At this place : Thanks to helpful explanation about the SCC’s functionality from a very kind local UNIX and Solaris consultant (Who said to me ~ “It’s my job I should know how to fix that.”). Thanks to him I tried powering up the system without any disk drives and the SCC pulled. OBP greeted me with errors on missing IDprom but went straight to a standard ‘ok’ prompt, now I had something to work with…

How i unbricked my particular machine:

  • The SCC card had to be removed (the box was powered off – it is NOT hot-pluggable)
  • Next a IDE CD-ROM was connected to the onboard IDE port (thanks to my dad who keept a nice stock of old computer parts)
  • With the hard disks pulled I powered the server on and let it boot to OBP, ending up some errors about the IDprom missing but a plain ‘ok’ prompt
  • Insert the disk with the OS and issue ‘probe-scsi’: The SCSI disk in question was recognized by OBP, ok.
  • Issue ‘probe-ide’ shows that the IDE CD-ROM was recognized (I realized a DVD writer didn’t work, thatis why I used the CD-ROM drive)
  • Inserted a Solaris 8 CD (9 or 10 should work too, not 11 with the removal of sun4u support) and hit ‘boot cdrom -s’ (boot cdrom launches the installer, -s goes into single user mode)
  • The first attempt without SCC always failed with card not inserted (missing IDprom…) but repeating it boots Solaris from the CD.
  • After some waiting a Solaris shell was ready

Without the SCC inserted, there was not network, nonetheless, things got more interesting from there

# List disks and get its name with
format

# Create temporary folder as mount point 
mkdir /mnt/recovery

# Mount the local SCSI disk and switch to its /etc
mount /dev/dsk/c1t0d0s0 /tmp/recover
cd /tmp/recover/etc

Now being in a chroot environment as root allowed me to modify /etc/passwd. Due to the fact that both sed and vi were different on Solaris 8 from what I knew from Linux and the BSDs I opted to make copy of /etc/passwd and /etc/shadow and use sed (there is no -i as in GNU sed) to replace the hash of the root password by nothing. (Source about /etc/passwd)

This resulted in an OS with a an empty root password. Time to exit the chroot environment and shut down the OS booted from the CD. Next I could insert the SCC back since that was the thing blocking the access to the rest of the system. As expected the OS was “kind enough” to accept an empty password for the root user the next time it booted from the hard disk.

Unfortunately I didn’t keep notes from that stage but from manpage it says the eeprom binary is platform-specific and located in a platform-specific folder, but anyway:

  • ‘eeprom’ showed that the ‘security-mode’ was set to ‘command’
  • ‘eeprom security-mode=none’ means the system should stop asking for a firmware password
  • ‘scadm’ can also then be used to re-set the ALOM password as well
  • Once done, reboot the OS and voilà: OBP is unlocked ! Additionnaly ALOM for remote management was now accessible too.

Was it economical? Nope, but it was a fun brain-twisting experience.

2016.02: Fix specs, the Sun Fire v210 and v240 only have U160 SCSI controllers, not U320 as I initially wrote.

December 3, 2015

Posted In: Uncategorized

Tags: , , ,

Leave a Comment

Finding a host via its MAC

Just something quick, when you have to find the IP address of a host that is tacking its MAC address via DHCP – and you don’t have access to the DHCP server in charge and its logs about given leases. There are a couple of ways doing so, and mine is likely not the most ideal one…

A couple of tools exist to scan your local network completely using nmap or arp-scan:

# nmap  -sn xxx.xxx.xxx.xxx/24

# arp-scan --interface=em0 -l

If you know the MAC address and don’t want to blast the whole network with broadcasts (although for a short time) you can use arping:

# arping 00:00:00:00:00:00

For sure the IP in use has to be within the same IP subnet since it sends broadcasts to the network in the IP level which ARP resolves to a given MAC address. Since ARP is not use for routed traffic this won’t help you if that machine is in another subnet.

December 3, 2014

Posted In: Uncategorized

Tags: , ,

Leave a Comment

BSDnow.tv OpenVPN tutorial: Full tunnel add-on

Recently I had the need to get myself a VPN since I was more travelling and had to use networks with proxies that not only blocked illegal sites, but yielded timeouts on perfectly legal content. Using BSDnow‘s excellent OpenVPN tutorial I whent ahead in a breeze.  But normally I use OpenVPN to connect to a remote (internal) network. This time I it needed to pass all traffic through the VPN so I could access the net ignoring local proxies.

As the tutorial mentions, adding push “redirect-gateway def1 bypass-dhcp” to the server’s openvpn.conf temporarily overrides the client-side default gateway forcing all traffic throug the VPN, that’s what I needed. Another (later on added) line was “topology subnet” since otherwise each client only gets a /32 subnet per connection which makes things a bit hairy at the next stage. tun0 on the server side then uses a /24 by default. “Large” missing piece for my use case was pf to NAT the VPN clients through the box to the internet. Here is the minimal ruleset for /etc/pf.conf I used:

ext_if = "vtnet0"
vpn_if = "tun0"

vpn_net = "10.8.0.0/24"

nat on $ext_if from $vpn_net to any -> ($ext_if)
pass in on $ext_if inet proto tcp from any to ($ext_if) port 22
pass in on $ext_if proto tcp from any to any port 1194

I had to declare vpn_net since instead of i.e. a $vpn_if:network since at boot pf doesn’t know the network tun0 uses before OpenVPN comes up. Then it just NAT’s traffic arriving from VPN network on tun0 to the external interface. The 2 other rules let me SSH to the VM and allows OpenVPN traffic.

Since this setup needs forward traffic (two) network interfaces I had to enable packet forwarding, in the end all it needed was:

# sysrc gateway_enable="YES"
# sysrc pf_enable="YES"

To avoid a reboot and enable forwarding right now:
# sysctl net.inet.ip.forwarding=1 

Start pf and restart OpenVPN
# service pf start
# service openvpn restart 

Just in case: Make sure pf.conf is really loadable
# pfctl -f /etc/pf.conf

And that’s about it. It’s not a full tutorial, but just an add-on to the one over at BSDnow for those situations where you need a full tunnel for $REASON (and no, ToR isn’t always a working solution). A big thanks to the Adam McDougall, the original author and helping hand – and the BSDnow crew for their high quality content!

September 17, 2014

Posted In: Uncategorized

Tags: , , ,

One Comment

Java WebStart and >= TLS 1.0 – oh why…

An awful lot of security issues has lead Oracle to tighten things when it comes to Java WebStart as it is used in an awful lot of KVM over IP solutions. Some of those systems are even very picky on the Java version used. *blimey*

Now I had those shiny new IBM SystemX x3650 m4 and a x3550 m4 that I was exploring when I was documenting settings for their remote service processor. In IBM (soon Lenovo?) SystemX M4 series this thing is called IMM2 (Integrated Management Module 2) and once you have installed it with a (not so cheap) license key you get a shiny remote KVM ability.

I was unfortunate to look at the documentation and to discover the CLI parameter ‘tls’:

system> help tls

  usage:
   tls [-options] - configures the minimum TLS level
   -min <1.0 | 1.1 | 1.2> - Selects the minimum TLS level
   -h - Lists usage and options

system> tls
-min 1.0

So I though: “TLS 1.0 is aging let’s at least bump it to 1.1”. – Until that moment the remote management capability worked pretty well beyond some random Java quircks. But unfortunately I tried out a couple of settings so at first it wasn’t obvious that it was due to this that Java stopped loading the Avocent KVM over IP applets and instead got greeted by this:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
	at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
	at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
	at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
	at sun.security.ssl.InputRecord.read(Unknown Source)
	... 20 more

OK, why did that happen – I though TLS 1.1 was supported by Java 7 for som time now- right?

  • Java 6 did only support upt to TLS 1.0
  • Java 7 (at least up to Update 55) did add support TLS 1.1 and TLS 1.2 but actually never enabled it by default
    If you want to enable it, open the Java Control Panel (javacpl) and enabled the newer TLS versions
  • Java 8 seemingly comes with TLS 1.1/1.2 enabled by default

If I had properly read the error message (*dou*) I would have far more quickly realized where to look for.

Curently you have to either set IMM2’s TLS version minimum to 1.0 (default) or fix your Java to allow newer TLS version.

 

May 5, 2014

Posted In: Uncategorized

Leave a Comment

“Hidden” CLI interface on Netgear GS110TP

The price difference between cheaper “smart managed” and the higher priced “fully managed” switches is often made up by removing a) serial console access and b) disabling access to a remote CLI. After working more often with managed switches I really appreciate a CLI access since most GUIs I’ve so far used (Netgear, HP-H3C Comware, Cisco IOS) were not much of a pleasure and most often slow. Serial console was less of use but it becomes very handy if the device doesn’t want to boot or for initial configuration.

Some vendors restrict or hide CLI access on their larger smart switches – maybe for support or developer purpose – one that I know about was the HP 1910’s that I’ve used (formerly H3C-based 3Com 2928). It was during a port scan on my GS110TP where I realized there were more than the expected HTTP and HTTPS ports responding. After increasing the scope to a full TCP  scan I saw 2 ports in the upper range that took my interest:

# nmap -p 1-65535 -T4 -A -v <ip>
[...]
Completed NSE at 08:44, 35.57s elapsed
Nmap scan report for myswitch.net.example.org (<ip>)
Host is up (0.011s latency).
Not shown: 65528 closed ports
PORT      STATE    SERVICE         VERSION
22/tcp    filtered ssh
23/tcp    filtered telnet
80/tcp    open     http?
|_http-methods: HEAD GET OPTIONS
|_http-title: NETGEAR GS110TP
161/tcp   filtered snmp
443/tcp   open     ssl/https?
| ssl-cert: Subject: commonName=<removed>
[...]
4242/tcp  open     vrml-multi-use?
60000/tcp open     unknown
[...]

For sure the default telnet and ssh didn’t return anything interesting, but there were TCP 4242 and TCP 60000 remaining. Apparently 4242 isn’t to much use, possibly a management interface for Netgear but it seems to have been detected by others for a couple of Netgear switches. During a quick search I came across a post from Koos van den Hout who had detected a telnet server on a larger, rackmount GS716T using an older firmware, thus at least there was a trace for Netgear to have a “hidden” CLI access for some of their larger smart switches. I tried my luck using a telnet client on my tiny 10-Port switch and what I got resembled much to Koos’ GS716T.

(Broadcom FASTPATH Switching) Applying Interface configuration, please wait ...

I continued as follows: Since GS110TP doesn’t allow defining different users nor RADIUS-based management authentication tried what Koos suggested and used the default ‘admin’ user as found on larger switches that do have user name for login.  This resulted in a password prompt. To get full access, enter ‘enable’ and enter twice (Cisco IOS – anyone?).  Now I can confirm that this works for the GS110TP running version 5.4.2.10, and likely the GS108Tv2 (uses same firmware image):

(Broadcom FASTPATH Switching)
Applying Interface configuration, please wait ...admin
Password:*******************
(Broadcom FASTPATH Switching) >
(Broadcom FASTPATH Switching) >?

enable                   Enter into user privilege mode.
help                     Display help for various special keys.
logout                   Exit this session. Any unsaved changes are lost.
passwd                   Change an existing user's password.
ping                     Send ICMP echo packets to a specified IP address.
quit                     Exit this session. Any unsaved changes are lost.
show                     Display Switch Options and Settings.

(Broadcom FASTPATH Switching) >enable
Password:
(Broadcom FASTPATH Switching) #show version
Switch: 1

System Description............................. GS110TP
Machine Type................................... GS110TP
Machine Model.................................. GS110TP smartSwitch
Serial Number.................................. [...]
FRU Number.....................................
Part Number.................................... BCM53312
Maintenance Level.............................. A
Manufacturer................................... 0xbc00
Burned In MAC Address.......................... [...]
Software Version............................... 5.4.2.10
Operating System............................... ecos-2.0
Network Processing Device...................... BCM53312_B0
[...]
Additional Packages............................ FASTPATH QOS
                                                FASTPATH IPv6 Management
                                                iÞä°cüå|Ø

(Broadcom FASTPATH Switching) #configure
(Broadcom FASTPATH Switching) (Config)#

As you can see at the end, even going into config mode is possible. If you are familiar with the Cisco IOS CLI you’ll realize how similar things are on the Netgear switches (Google tells us FASTPATH is from Broadcom). Also you can have a look at Netgear’s M4100 or M5300 CLI guides to get a closer idea of the CLI command usage, though not all commands are available on this box. If you change things via CLI, remember to save the running config to the NVRAM’s startup config which is what the web UI automatically does for you. (#copy system:running nvram:startup-config)

Warning: Some commands cause instant reboot
However, as Koos for the GS716T already confirmed, certain commands don’t seem to be recognized and may cause an instant reboot of the switch without saving to the NVRAM (i.e. #ip ssh server enable). That might be the cause why Netgear preferred disabling regular CLI access on this firmware since they didn’t want to support it. Still it can be quite useful to know that even on such a small entry-level manageable switch, there is still a  CLI available in case you need it.

February 11, 2014

Posted In: Uncategorized

Tags: , ,

6 Comments

Quick-tip: Put the UniFi wireless controller on a separate LV

I’ve been running a Ubiquiti UniFi wireless controller in production for a while known that it requires quite some amount of storage. But it heavily depends on how many APs and users you are having, larger setups will have to take that into account earlier, others might just be happy with it. As Ubiquiti states for auditing purpose the UniFi server keeps a lot of date around which can easily grow a couple of gigabytes per – let’s say 4 months – in my current experience. In the Debian and Ubuntu packages the data from the controller is principialy located in:

  • /var/lib/unifi: Database, AP config files
  • /usr/lib/unifi: Firmware binaries, base config files

For other platforms like FreeBSD it might be else where like somewhere in /usr/local/…

The first one seems to be the one to take care little more closely. While it will initially grow to roughly +3GB at first run the MongoDB preallocation files are generally OK and disabling journaling isn’t worth the risk and hassle during power outage either. However this can easily grow and if you forget about it, it might fill up the partition and either cause other services to stop working (actually 2.4.x seems to continue quite happily as long as you don’t try adopting new APs, that’s when I experienced problems)*

Anyhow from lessons learned I’d suggest putting at least “/var/lib/unifi” on a separate partition , or (likely easier to grow online) a LVM logical volume and have it mounted there. – For sure if you have something like ZFS things are even easier by creating a new ZFS and adding a mountpoint to it with some limitation so it doesn’t outgrow the other disk space available. Of course you have to stop the unifi daemon first, create that new volume/fs move the data over there and be happy.

Afterwards consider to look at Ubiquiti’s pruning script in their FAQ and decide how much data you really need to retain and consider pruning on more-or-less regular basis. I hope putting it on a extra volume keeps me

* The config files for a new AP can’t be written to disk, thus the newly adopted AP won’t get any valid config and you then might have to forgt, reset and re-adopt the AP to get it working.

January 7, 2014

Posted In: Uncategorized

Tags: , ,

Leave a Comment

A low-power FreeBSD journey: High resolution terminal

Certainly managing a Unix-like server includes SSH and less often local console the screen resolution on the local console isn’t much of a matter, though having a little bit more than the standard can be nice when browsing through large files or grepping through logfiles. Thankfully as I learned, on the current (yet upcoming) FreeBSD 10 the GENERIC kernel is coming with reasonable defaults which limits the effort for high(er) resolution terminal to a minimum, or in short:

echo "allscreens_flags="MODE_280" >> /etc/rc.conf
reboot

… OK that’s definitely to short to be helpful. This article in the FreeBSDwiki.net is quite good for me as beginners but, but it starts about having to recompile your kernel with VESA included. Right, not particularly something I’d like to do first just to get a better resolution right on a server’s console? Actually it seems that FreeBSD 10.0-RC3 on amd64 (at least) have the vesa driver built into the GENERIC kernel. The section of how to compile your own kernel is not required (anymore?). Just check your available modes, test it before messing up rc.conf and be happy.

# To check the available modes
vidcontrol -i mode

# To test your chosen mode works 
# FIXME: You do unmess if it doesn't except from rebooting?
vidcontrol MODE_280
# Once successful put the appropriate line in your rc.conf
allscreens_flags="MODE_280"

MODE_280 equals to 1024×768 in 24-bit colour which isn’t exactly considered a high resolution to current standards but still more pleasant than the mere 80×25 characters yet still not too big for my smallest and oldest screen in the back of my cellar (i.e. a regular 4:3 15″ TFT) . Finally I should add that the FreeBSD handbook also contains a worthy-to-read section on this topic – and apparently it seems sufficient to load the vesa module with kldload. Though, not having an older release available I can’t relly check back. Another similar post can be found on this blog.

December 29, 2013

Posted In: Uncategorized

Tags:

Leave a Comment

FreeBSD: How git and OpenLDAP server can collide via openldap24-(sasl-)client

I’ve have been doing some progress on my journey with bare FreeBSD, the BSDNow.tv tutorials are good and provide reasonable defaults to get started quickly. I quicklygot both a poudriere package builder inside a VM of my workstation and ezjail up and running on a small homeserver with an Atom CPU (that is quite not that quick a building). I actually wanted some extra switches enabled in my self-built packages not present in the binaries frome from pkg.freebsd.org.

One jail would become a testbed for OpenLDAP I configured poudriere to build net/openldap24-server (default, except with SASL as enabled in i.e. Debian)  and since I like and use: devel/git (default). When I wanted to install git AND the OpenLDAP package in this jail, pkg  ended ith an obscure message telling me that files in openldap24-client conflicted with openldap24-sasl-client. Following the dependencies I tried to find the cause of the dependency conflict:

  • devel/git depends on  ftp/curl (default)
  • ftp/curl was (non-standard) configured to support LDAP and LDAPS since I want to play with LDAP:
    • That is what caused a dependency on openldap24-client for git.
    • Most other packages will do so once LDAP/LDAPS support is enabled (i.e. php5) – not on openldap-sasl-client.
  • net/openldap24-server with SASL results
    • in a package called openldap24-sasl-server (not openldap24-server!)
    • in a dependency of the server package depending on openldap24-sasl-client
  • Both openldap24-sasl-client got built and openldap24-client were almost identical (beyond SASL-support) and thus they conflict since they provide the same thing

I wanted SASL support but also git and curl. For whatever reason to fix this was to change make.conf as follows:

WANT_OPENLDAP_SASL=yes

Using poudriere and a build jail called 10amd64, this was in: /usr/local/etc/poudriere.d/10amd64-make.conf.  Afterwards I (preferred to) completely rebuild all  package to make sure all package would take that switch (with -c):

poudriere -f /path/to/list-of-pkgs -j 10amd64 -c

Afterwards on the destined ldap server  both git and openldap-(sasl)-server now depended on openldap-sasl-client and could be installed alongside:

 # pkg install git openldap-sasl-server
Updating repository catalogue
The following 19 packages will be installed:

        [...]
        Installing cyrus-sasl: 2.1.26_3 [1Labs]
        Installing openldap-sasl-client: 2.4.38 [1Labs]
        Installing curl: 7.33.0_1 [1Labs]
        Installing openldap-sasl-server: 2.4.38 [1Labs]
        Installing git: 1.8.4.3 [1Labs]

The installation will require 279 MB more space

20 MB to be downloaded

Proceed with installing packages [y/N]:y

Unfortunately I wasn’t able to quickly find a reliable source why that switch has to be placed or is more closely explained. It can be found in a couple of packages, likely someon with more thorough FreeBSD experience would be able to bring a correct cause. It thoug causes packages with LDAP dependency to move their dependency from the normal to the sasl-enabled OpenLDAP client. At least, once I found about WANT_OPENLDAP_SASL, finding others who had this issue wasn’t difficult at all, i.e.

December 9, 2013

Posted In: Uncategorized

Tags: , , ,

Leave a Comment