Posted by Benjamin Close on April 14, 2010 under FreeBSD | 
Recently a port audit security advisor was released that indicated an exploit with sudoedit of the security/sudo FreeBSD port. At the time I was running sudo 1.6.9 and being a responsible system administrator, I decided to upgrade sudo to the latest revision of the port (1.7.2p2 at the time). The upgrade went very smoothly, with portupgrade doing it’s job quickly and reliably. It wasn’t until I tried to use sudo for the first time after the upgrade that the problems started.
Initially I tried get a root shell using:
sudo -s
sadly after repeated password prompts I had no luck. Initially I thought I was just getting my password wrong – something I occasionally do with the amount of passwords I have to remember. However, after repeated attempts I came to the conclusion that something else was wrong.
I looked at the logs to see if they would show anything useful:
Apr 14 11:49:28 leo sudo: benjsc : 1 incorrect password attempt ; TTY=pts/3 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Apr 14 11:51:09 leo sudo: benjsc : 1 incorrect password attempt ; TTY=pts/4 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Apr 14 11:58:03 leo sudo: benjsc : 1 incorrect password attempt ; TTY=pts/4 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Apr 14 11:58:16 leo sudo: benjsc : 1 incorrect password attempt ; TTY=pts/4 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Once again nothing obvious showed up. At this point I started Googling to try and find the answer. There was a lot of articles about people trying the root password rather than the user password, but I wasn’t doing that. There was articles about people stuffing up the syntax of the sudoers file (you should use visudo to edit this). However, nothing had changed but the version of sudo. Eventually I found a post that solved the issue.
It turns out that the latest versions of sudo break pam support. Whilst the article refers to OPIE (One Time Keys), I’ve since confirmed that this issue affects machines without OPIE setup. Hence for anyone who tries to upgrade sudo to a later version and has problems with their password not being accepted, and the password prompt just continuing to reappear. Then you’ll need to patch sudo to work.
How, copy and paste the following on the console:
cd /usr/ports/security/sudo
make extract
cd work/sudo*
patch << END
--- auth/pam.c.orig 2010-02-04 10:43:28.635212518 -0600
+++ auth/pam.c 2010-02-04 10:43:34.194558424 -0600
@@ -107,13 +107,6 @@
}
/*
- * Set PAM_RUSER to the invoking user (the "from" user).
- * We set PAM_RHOST to avoid a bug in Solaris 7 and below.
- */
- (void) pam_set_item(pamh, PAM_RUSER, user_name);
- (void) pam_set_item(pamh, PAM_RHOST, user_host);
-
- /*
* Some versions of pam_lastlog have a bug that
* will cause a crash if PAM_TTY is not set so if
* there is no tty, set PAM_TTY to the empty string.
END
cd ../..
make build
make deinstall
make install
Posted by Benjamin Close on January 8, 2010 under FreeBSD, UniSA |
Recently I was working on a php command line program that required access to a serial port.
Initially developed under Linux the program was then shifted to it’s permanent location on a FreeBSD server. This is where we first started having problems. Initially we discovered the server didn’t have a native serial port. We fixed this using a USB to serial converter/dongle (FTDI Chipset). This was fine as FreeBSD has the ufdti kernel module. Upon loading the module new devices appears in /dev
crw-rw---- 1 uucp dialer 0, 157 Oct 6 08:39 /dev/cuaU0
crw-rw---- 1 uucp dialer 0, 158 Oct 6 08:39 /dev/cuaU0.init
crw-rw---- 1 uucp dialer 0, 159 Oct 6 08:39 /dev/cuaU0.lock
crw-rw-rw- 1 root wheel 0, 154 Jan 8 10:50 /dev/ttyU0
crw------- 1 root wheel 0, 155 Oct 6 08:39 /dev/ttyU0.init
crw------- 1 root wheel 0, 156 Oct 6 08:39 /dev/ttyU0.lock
We attempted to connect to our device using screen (screen /dev/ttyU0 115200) and everything worked as expected. We could send AT commands to the device all ok.
We then stopped screen and ran our php program. It ended up hanging on a fgets call to the serial port. This is really strange we though.
Next we queried the port to find out what baud rate it was set at:
>stty -f /dev/ttyu0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb
Strange we thought as we’d just connected with screen at 115200. Under linux we use screen to set the baud rate, all other programs accessing the port use the port at 115200. So what had set it back to 9600 baud?
We tried to use stty to set the speed:
>stty -f /dev/ttyU0 speed 115200
>stty -f /dev/ttyu0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb
What on earth was happening? We set the speed to 115200 but directly quering the port again indicated it was still at 9600 baud? At this point we were perplexed.
Eventually we found the solution. The newer FreeBSD terminal drivers provide the *.init devices, in this case /dev/ttyU0.init . These devices indicate the terminal settings to be applied to the terminal when the device is closed. Whilst Linux leaves the device in the same state the last program put the port into, FreeBSD restores the terminals state to what ever is specified in the init file. So a quick command:
> stty -f /dev/ttyU0.init -icanon -isig -echo echoe echok echoke echoctl -icrnl -ixany -imaxbel ignpar -opost -onlcr -oxtabs cs8 -parenb -hupcl clocal
And then to check:
> stty -f /dev/ttyU0
speed 115200 baud;
lflags: -icanon -isig -echo echoe echok echoke echoctl
iflags: -icrnl -ixany -imaxbel ignpar
oflags: -opost -onlcr -oxtabs
cflags: cs8 -parenb -hupcl clocal
Excellent. The terminal was now configured exactly how we wanted. We ran the program and it worked like a charm!
Posted by Benjamin Close on April 1, 2009 under Mythtv |
This article is the first in a series of blog entries which documents my progress getting FreeBSD 7.1-Stable working a both a MythTV backend and frontend. There’s very little information out there talking about this process, probably as FreeBSD’s multimedia drivers are not as mature or as abundant as Linux’s . However there is some information out there alluding to clues that is it possible. Below is the specs of the computer I’m using for this setup.
Hardware
- CPU: Core2Duo E8200 @ 2.66GHz
- HDD:
ad0: 114472MB <WDC WD1200JB-00FUA0 15.05R15> at ata0-master UDMA33
ad4: 305245MB <WDC WD3200AAKS-00B3A0 01.03A01> at ata2-master SATA150
ad6: 190782MB <Seagate ST3200822AS 3.01> at ata3-master SATA150
ad7: 190782MB <Seagate ST3200822AS 3.01> at ata3-slave SATA150
- Video Card:
NVideo GeForce 7300 LE
- Audio:
Intel 82801G (ICH7 Family) High Definition Audio
- Capture Cards:
-
- CX2388x TV Capture Chip (DVB-T)
- Conexant (Was: Brooktree Corp)
’7610144D&REV_02\4&1F7DBC9F&0&09F0 TV Video Capture
With the hardware set and not likely to change (I refuse to buy hardware due to an O/S not working with what I’ve got), it was time to try and get things working. Whilst there is a mythtv port, it’s the old stable release of 0.18. There has been a lot of changes since then. Including the new libmythui library where groovy graphics features are available. I must admit I’m not coming in to this blind. I’ve been running mythtv under Linux for quite some time. Hence I’m quite aware what needs to be done under Linux to get a working Mythtv setup. Hence I’ll break this article up into a number of different steps as below. Each one being a different blog entry.. some of these steps are going to take a while to get working!
- Setting up required ports
- Setting up capture cards
- Setting up audio
- Setting up Xorg
- Installing Mythtv
- Configuring Mythtv
- Tweaking Mythtv
For anyone who wishes to follow this drama of getting things working below I provide some links I’ve found which useful in determining what might be possible. I also provide a little justification as to why I want Mythtv working under FreeBSD.
Why the Switch?
After having mythtv successfully running under various versions of ubuntu, I finally reached a point where Linux annoyed me enough to try and get rid of it in favour of FreeBSD. It’s not that Linux didn’t work, it’s just the amount of stuffing around I had to do to get things working was CRAZY! Sure installing mythtv was relatively easy but it’s all the little things that FreeBSD does so well that Linux doesn’t that made me want to change. Thinks like power management, cpu throttling, wireless that actually works!
These things are just easier under FreeBSD, there’s no config, overiding some config, linked to some default, using some crazy symlink farm. There’s not ‘volatile’ kernel modules which must go through crazy loading scripts because they are not GPL compliant. FreeBSD also is much easier to upgrade in place and has the ZFS filesystem. This is the main reason I wanted to switch. I use the same machine as a backup server with 2 disks in raid 1. The ability to daily snapshot at the filesystem level is just soooo nice!
FreeBSD Mythtv Links
Below are some links that I found useful when getting mythtv working under FreeBSD.
- http://mythtv.son.org/tiki-index.php
- http://wiki.freebsd.org/MythTV
- http://www.lemis.com/grog/HOWTO/mythtv-on-FreeBSD-setup.html
Posted by Benjamin Close on November 7, 2008 under Computers, FreeBSD |
This article describes how to setup Frox to perform transparent proxying and caching via pf under FreeBSD.
Read more of this article »
Posted by Benjamin Close on under FreeBSD |
Dual Booting Windows Vista & FreeBSD / Linux / Some other OS
The Problem
After installing Windows Vista Enterprise Edition, I very quickly wanted to get back to FreeBSD. As per previous versions of Windows, Vista does a great job of overwriting the Master boot record (MBR). Unlike previous versions of windows, you cannot just install a different boot loader in the MBR – so I found out the hard way. (It used to be sooo easy fdisk /mbr would fix any broken boot sectors, then just install your favourite boot loader). Read more of this article »
Was this helpful?
Throw some money in the tip jar
