I recently implemented BLF ring/call indication in my home asterisk setup. And once I had the call indication, I also wanted to be able to pickup a remote call. Of course Asterisk provides ways to achieve this, but those pick up the phone call immediately. At my workplace, the remote pickup feature would make your own phone just ring, giving you a chance to know who's calling and to decide about whether or not you want to take the phone call at all. This is way cooler than directly being connected to god-knows-who. So, I want it.
I've been working on Fluxmon for quite a while now, so I thought it was time to give a little status update. I've done quite a lot of research in the meantime, upon which I can now base the conclusion that I don't know jack shit about what I'm doing.
The hardest issue is figuring out what it is that I actually want to do.
All the cool Active Directory authentication stuff I wrote about requires machines to be joined into the domain. This process involves entering an administrator's password on every machine that is to be joined, which can be quite cumbersome if you have a large number of machines. In a cloud environment where machines are to be automatically deployed and provisioned, manually entering an admin password is downright unacceptable.
However, since the only step that actually requires the password is the
kinit command, there's a way around using passwords: We can simply store a keytab on the box that contains the password, and then use the keytab to authenticate to the domain. Then, we won't require any passwords at all.
If you're running Linux servers in a Windows domain, it would be pretty cool if Domain users could authenticate to your servers using their domain credentials and then sudo to root. But of course you'll want to prevent each and every user having access to all your servers. Instead, you'll want to restrict access to members of a specific user group.
This howto shows the basic steps needed to allow members of the "admins" group to login and get a shell.
If you're working on a Linux notebook in an Active Directory environment and frequently accessing file shares, you'll soon find yourself annoyed by typing your password all the time. At least, I did. I thought it would be cool to use Kerberos (it is designed for just that use case), but completely rewiring my laptop's auth system to auth using Kerberos wouldn't work because when I'm on the move, there won't be no Domain Controller available, so I wouldn't be able to log in. This is obviously not acceptable.
I came up with a solution that works for me pretty well: My domain user and my local user have the same username and password. I chose to keep it that way, and just instruct PAM to try to reach the DC, and if successful, acquire a Kerberos ticket using the password I just entered. In case this worked, I'd have a Kerberos ticket for my session that I could then use to access file shares or kerberized web servers.
There are quite a few tutorials on how to join a Linux machine into a Windows Domain. Some of them are outdated and talk about old-style domains instead of Active Directory. Others require the Active Directory schema be extended. Most of them neglect configuring the system so that Kerberos can be used correctly. And almost none of 'em show how to configure stable user IDs that are reproducible across multiple systems, so using NFS and DRBD will actually work instead of completely breaking permissions.
So, here's my own howto which fixes all of this. It lays out the config I use in my home samba4 domain,
LOCAL.LAN. (Yes, I do have an Active Directory domain at home. I like it, even. This is how crazy I am.)
Yesterday in the office, we were using a projector to collaborate on something. We had turned off the lights and lowered the blinds in order to improve the projector's readability. My screens are of course configured for a brightly-lit room, so I was now staring into two enormously bright screens which hurt my eyes incredibly.
On a laptop, I would just turn the brightness down without really thinking about it. But with standard desktop displays, this involves digging through the display's on-screen menu, fiddling with knobs that only work part of the time, and the prospect of having to repeat this step when we're done working to get back to normal. This sucks. So I looked for a way to set the brightness in software.
The LM385 voltage reference is well under way of becoming my favourite element. Last time I ordered a bunch of electronics, I also included a couple of KTY81-121 temperature sensors, and when trying to make sense of the values, the LM385 proved to be incredibly useful again: I'm powering the Arduino circuit via the FTDI cable using my notebook's power while developing the sketch. However, the notebook's voltage varies heavily, which is one of the reasons why I couldn't get a sensible reading.
I've always wanted to know how a bench power supply works. It's always been a mystery to me what happens in between 230V AC going in one one side and 3 to 15V DC popping out at the other — and especially, how the thing survives being shorted so painlessly. I've also always wondered how my digital multimeter works. So when I was looking for something to do with my Arduino recently, I had the idea of building a power supply that also takes measurements and reports on the current and maybe other things.
I'm surprised by the amount of knowledge that can be gained through such a seemingly simple project.