While we were on vacation back in the States during the summer, our camera started doing strange things with the flash, so we decided it was time to get a new one. After much reading and debating, we settled on the Samsung NX300M. It’s been a major step up from our old point and click, and we’ve enjoyed the quality of the shots a lot.

Being the nerd that I am, I started wondering what OS powered the camera and whether it was hackable. After doing some in-depth research (typing “hack NX300M” in Google), I came across these two fascinating articles about the NX300. Basically, any code that you put in autoexec.sh in the root directory of your SD card will be run as root during camera bootup. I immediately tried to make my own autoexec.sh on my NX300M, but, unfortunately, it didn’t work. After some experimentation, I found that the initial firmware for the camera (1.10) does run autoexec.sh, so I downgraded my firmware and got to work.

I decided to make the killer app for a Wifi-enabled camera (at least, I think it’s a killer app). The NX300M can do some pretty cool things with its built-in Wifi like acting as a hotspot so it can send pictures to your phone. It can also do some form of automatic backup to your Windows desktop, but, as we don’t have any Windows systems in our house, I was unable to try it. The annoying thing about the Windows automatic backup feature, though, is that you have to manually switch to the Wifi setting and choose “Auto Backup” to run it. If I’m going to be doing automatic backups from my camera, I want it to be truly automatic, oddly enough. And I want it to backup to my wife’s laptop, which is running Fedora, preferrably using a secure copy method like rsync over ssh or scp.

I spent several days trying to work out how to make this all work, and here are some notes from my attempt:

• There is one root filesystem and two support filesystems, all running ubifs.
• The root filesystem is read-only, and, though I can remount it as rw, any writes seem to go to /dev/null. I don’t understand ubifs enough to know whether this is expected behavior.
• The NX300M seems to be running the same ancient version of Tizen that the NX300 is, with a couple of proprietary binaries that do all the heavy lifting. Pretty much everything that Georg wrote about the NX300 in the above pages applied to the NX300M.
• Working out how to start Wifi from autoexec.sh was very difficult. The NX300M uses a very old version of connman plus a funky daemon called net-config to actually power up and down the Wifi card. Neither has a cli tool available on the NX300M to control it, and each can only be controlled via dbus. Running dbus introspection on net-config causes the camera to reboot. Who knew?
• /dev/log_main has a log of pretty much everything, including dbus commands. This is what I used to figure out what commands I needed to use to get the Wifi up.
• The NX300M comes bundled with an SSH client (though no SSH server), which makes the backup method pretty simple.
• Tizen has a power manager that’s run by the NX300M, but I’m not sure whether it’s actually being used. It appeared to me from the logs that the proprietary UI app was turning off the display and then the camera. To keep the camera from shutting off during the automatic backup, I ended up using xdotool to send keypresses to the UI. Yes, that’s ugly.
• The UI understands the concept of time zones, but everything at the OS level is in UTC, and, at least as far as I can tell, the camera treats the UTC time as if it’s the current time zone.
• There is a rtc on the camera, but it doesn’t seem to support wakeup events. 🙁

So, in the end I was able to put together a script that runs on boot that checks for any new pictures and, if there are any, connects to our Wifi and scp’s them to my wife’s laptop. It then appends the filename to a hidden file in the DCIM directory on the SD card that keeps track of which files have been copied across. If my wife decides to rename the file or the folder it’s in, I don’t really want to send the picture across again.

I’m releasing my code under the GPLv2+, and it’s available on GitHub. I hope somebody finds it useful.

Disclaimer: This is not an official guide and in no way represents best practices for FreeIPA. It is ugly and involves the digital equivalent of bashing on screws with a hammer. Having said that, when nobody has invented the right screwdriver yet, sometimes you just have to hammer away.

First, some history. We’ve been running separate DHCP, DNS and LDAP servers since we switched from static IP addresses and a Windows NT domain somewhere around ten years ago. The DHCP server was loosely connected with the DNS server, and I had written this beautifully complex (read: messily unreadable) script that would allow you to quickly add a system to both DHCP and DNS. A few months ago, we migrated all of our users over to FreeIPA, and I started the process of migrating our DNS database over. Unfortunately, this meant that our DHCP fixed addresses were being configured separately from our DNS entries.

Last week I investigated what it would take to integrate our DHCP leases into FreeIPA. First I checked on the web to see if something like this had already been written, but the closest thing I could find was a link to a design page for a feature that’s due to appear in FreeIPA 4.x.

So here’s my (admittedly hacky) contribution:

1. sync_dhcp – A bash script (put in /srv, chmod +x)that constantly checks whether the DNS zone’s serial number has changed, and, if it has, runs…
2. generate_dhcp.py – A python script (put in /srv, chmod +x) that regenerates a list of fixed-addresses in /etc/dhcp/hosts.conf
3. dhcpd.conf – A sample dhcpd.conf (put in /etc/dhcp) that uses the list generated by generate_dhcp.py
4. sync-dhcp.service – A systemd service (put in /etc/systemd/system) to run sync_dhcp on bootup
5. make_dns – A script (chmod +x) that allows the sysadmin to easily add new dns entries with a mac address

sync_dhcp does need to know your domain so it knows which DNS zone serial to check, but other than that, the first four files should work with little or no modification. You will need to create a dnsserver user in FreeIPA, give the user read access to DNS entries, and put its password in /etc/dhcp/dnspasswd (readable only by root).

make_dns makes a number of assumptions that are true of our network, but may not be true of yours. It first assumes that you’re using a 10.10.0.0/16 network (yes, I know that’s not right; it’s long story) and that 10.10.9.x and 10.10.10.x IPs are for unrecognized systems. It also requires that you’ve installed freeipa-admintools and run kinit for a user with permissions to change DNS entries, as it’s just basically a fancy wrapper around the IPA cli tools.

Bent Screw Hole Backyard Metal Macros by Steven Depolo used under a CC BY 2.0 license