This site is now 100% read-only, and retired.

XML Logo

Posted by e5z8652 on Wed 30 Jan 2013 at 00:30
Tags: none.
I want to run OpenVPN on a Debian machine running as a service -- the full /etc/init.d/ and /etc/openvpn configuration, so that the VPN comes up when the machine boots, and without caring whether a particular user is logged in.

But I want to restrict use of the VPN to users in a certain group. (or perhaps prevent users in a certain group from using the VPN.)

I do not think iptables' user tag does what I would like, since OpenVPN does not run as the user so iptables can't tell who owns the packets. And that would not work at all for an SSH session back down the VPN tunnel, where I want to log in as a preferred user, but prevent logging in as another user.

Hmm. I've been away too long and my brain is full of cobwebs.

 

Posted by e5z8652 on Fri 1 Oct 2010 at 18:27
Tags: none.

Putting this in because I keep coming up with this from scratch. Might as well share with google. I think I remembered the important steps.

Debian web kiosk mode, with flash and java. For a simple kiosk leave flash and/or java out. For a keyboardless kiosk or display machine you do not have to perform steps 6.3 or 8. This is not especially hardened, but is suitable for environments where the machine can be casually watched.

1) install base debian install (do not select ANY options during tasksel at the end of install)

2) log in as root, install:

1. xserver-xorg-core

(xorg core)

2. fluxbox

(minimal window manager)

3. Iceweasel

(we need some firefox plugins)

4. unclutter

(hides mouse cursor when not being used - important for display kiosks)

5. sun-java6-plugin

6. flashplugin-nonfree

(flash and java needed for some websites - you may not need these)

7. openssh-server

(for remote management after display is locked down)

3) make a user named display, set a password

4) edit /etc/rc.local using your favorite editor (nano should be installed, as is vi):

add this line before the exit 0:

     su - display -c startfluxbox 2> /dev/null &

5) edit /etc/X11/Xwrapper.config:

1. change allowed_users=console to allowed_users=anybody

6) Go ahead and reboot, you should log in as display to a fluxbox desktop.

Switch back to VT1 and log in as root, then su - to display.

1. As display, edit ~/.fluxbox/autostart.sh

     unclutter &
     iceweasel &
     xset -display :0 dpms force on
     xset -display :0 dpms 0 0 0

The xset lines are useful for an unattended display kiosk that won't have keyboard or mouse activity, and turn off power management for the display. If you want the display to turn off after some period of inactivity, change the last line to appropriate values. (Read the xset man page.)

2. As display, edit ~/.fluxbox/init

Add this line to the end:

session.screen0.rootCommand: sh /home/display/.fluxbox/autostart.sh

3. As display, edit ~/.fluxbox/keys

find these lines and consider commenting them out:

     Mod1 F1 :Exec xterm
     Mod1 F2 :Exec fbrun
     Mod1 F4 :Close
     Mod1 F9 :Minimize
     Mod1 F11 :Fullscreen

These set up the alt+F1 key to bring up a terminal and the alt+F2 key to open the run command window. Either option would allow a user to type blindly behind the R-Kiosk Iceweasel window, but start a program (or kill Iceweasel) via command line. The alt+F4 key and alt+F9 keys would allow the user to close or minimize the Iceweasel window. The alt+F11 key would bring Iceweasel out of full screen mode, exposing the taskbar to the user. For a display only kiosk without a user accessible keyboard you shouldn't have to worry about these settings.

7) Reboot again, you should log in as display and have Iceweasel started.

1. With Iceweasel, install the TryAgain plugin and set the options you want (timeout, number of tries, etc.)

2. With Iceweasel, install the R-Kiosk plugin, but do not enable it yet.

3. Set Iceweasel's homepage to the page you want the kiosk to be at. Also run through Iceweasel and turn off features you don't want (tab bar, javascript, etc.) One thing to pay attention to is automatic updates of plugins. For a kiosk machine, especially one that is just displaying information, you do not want Iceweasel to take it upon itself to update the plugins. Turn this off.

8) Create an /etc/X11/xorg.conf file:

     Section "Serverflags"
        Option "DontVTSwitch"
     EndSection

This xorg.conf file disables the "ctrl+alt+Fn" key combinations used to switch to virtual terminals.

9) With Iceweasel, activate the R-Kiosk plugin. Then reboot. If you haven't restarted xorg after step 8, you can still switch to a virtual terminal to reboot. Otherwise, ssh in.

At this point you should have a fairly locked down browser session. Depending on what edits you made to .fluxbox/keys your users may have different options to deal with the browser. You should be able to access the box remotely via ssh as root for other management. Additional tweaking may be needed for your individual situation. For example, if you are using a large monitor over s-video, consider forcing the screen resolution in xorg.conf. You will probably want ntp installed, etc. Depends on your environment.

Edit:

With a kiosk machine, especially one connected to a large display (for advertising, etc.) there is a significant chance that the kiosk machine is rebooted when the display is powered off. Displays may be powered off at night to conserve power, and any maintenance on the kiosk machine is likely done at this time where a reboot cycle will not be visible to the public.

With the Squeeze kernel and KMS, if no display is detected you get no video. (I predict some frustrated traffic on web forums or e-mail lists when people start their desktop machines in the "wrong" order with Squeeze.) No video on a kiosk that has a main purpose of displaying video is an issue.

Luckily, the solution is quick and easy.

First, determine which video port you are using -- VGA, DVI, etc. and then tell the kernel to always turn that port on, even if the kernel does not detect a monitor attached to the port.

For example to turn on the VGA port edit /etc/default/grub and change

    GRUB_CMDLINE_LINUX_DEFAULT="quiet"

to

    GRUB_CMDLINE_LINUX_DEFAULT="quiet video=VGA-1:e"

The above example tells KMS to enable the VGA-1 port regardless of whether a display is detected on the port or not. The video= kernel argument has the syntax to set a specific display geometry and refresh rate, but the options are limited to what the BIOS will support. So I find it easier to just enable the port, and then create a stub xorg.conf file that uses a modes line in the display section to set the resolution you want. For example a kiosk I have is pushing video to a large screen TV at 1920x1080. That resolution doesn't work with the video= setting.

The video= commands aren't well documented, but there is some info here (which relates specifically to nouveau, but can be applied to other chipsets that KVM supports:)http://nouveau.freedesktop.org/wiki/KernelModeSetting

Edit: some clarifications in the instructions regarding editing files and settings.

Edit: When you update this system remotely, from time to time Iceweasel will pop up dialog boxes asking if you want the latest version of Try Again or R-Kiosk. For a kiosk with a mouse and keyboard, this isn't too much of a problem as you can just deal with the pop-ups locally. However for an advertising kiosk with no local keyboard or mouse this can be a problem. A tool that I use to get around this is the x11vnc package.

A) Install x11vnc

B) Create a wrapper script to start x11vnc for you. I called mine vnc_view.sh and put it in /usr/local/bin:

    #!/bin/bash
    sleep 60
    x11vnc -display :0 -env  FD_XDM=1 -auth guess -forever -passwd password &

The sleep command doesn't start x11vnc for a minute after boot, which gives xorg and fluxbox time to set up. If you leave this out, x11vnc will try to start before the xorg environment is ready. After the pause x11vnc is started in the background.

C) Call the wrapper script from rc.local, after you start fluxbox:

    /usr/local/bin/vnc_view.sh

You can now interact with the desktop using a vnc client to clear dialog boxes that appear after an iceweasel upgrade.

Good luck.

 

Posted by e5z8652 on Tue 12 Oct 2010 at 18:50
Tags: none.

Putting this in because I keep coming up with this from scratch. Might as well share with google. I think I remembered the important steps.

Debian web kiosk mode, with flash and java. For a simple kiosk leave flash and/or java out. For a keyboardless kiosk or display machine you do not have to perform steps 6.3 or 8. This is not especially hardened, but is suitable for environments where the machine can be casually watched.

1) install base debian install (do not select ANY options during tasksel at the end of install)

2) log in as root, install:

1. xserver-xorg-core

(xorg core)

2. fluxbox

(minimal window manager)

3. Iceweasel

(we need some firefox plugins)

4. unclutter

(hides mouse cursor when not being used - important for display kiosks)

5. sun-java6-plugin

6. flashplugin-nonfree

(flash and java needed for some websites - you may not need these)

7. openssh-server

(for remote management after display is locked down)

3) make a user named display, set a password

4) edit /etc/rc.local using your favorite editor (nano should be installed, as is vi):

add this line before the exit 0:

     su - display -c startfluxbox 2> /dev/null &

5) edit /etc/X11/Xwrapper.config:

1. change allowed_users=console to allowed_users=anybody

6) Go ahead and reboot, you should log in as display to a fluxbox desktop.

Switch back to VT1 and log in as root, then su - to display.

1. As display, edit ~/.fluxbox/autostart.sh

     unclutter &
     iceweasel &
     xset -display :0 dpms force on
     xset -display :0 dpms 0 0 0

The xset lines are useful for an unattended display kiosk that won't have keyboard or mouse activity, and turn off power management for the display. If you want the display to turn off after some period of inactivity, change the last line to appropriate values. (Read the xset man page.)

2. As display, edit ~/.fluxbox/init

Add this line to the end:

session.screen0.rootCommand: sh /home/display/.fluxbox/autostart.sh

3. As display, edit ~/.fluxbox/keys

find these lines and consider commenting them out:

     Mod1 F1 :Exec xterm
     Mod1 F2 :Exec fbrun
     Mod1 F4 :Close
     Mod1 F9 :Minimize
     Mod1 F11 :Fullscreen

These set up the alt+F1 key to bring up a terminal and the alt+F2 key to open the run command window. Either option would allow a user to type blindly behind the R-Kiosk Iceweasel window, but start a program (or kill Iceweasel) via command line. The alt+F4 key and alt+F9 keys would allow the user to close or minimize the Iceweasel window. The alt+F11 key would bring Iceweasel out of full screen mode, exposing the taskbar to the user. For a display only kiosk without a user accessible keyboard you shouldn't have to worry about these settings.

7) Reboot again, you should log in as display and have Iceweasel started.

1. With Iceweasel, install the TryAgain plugin and set the options you want (timeout, number of tries, etc.)

2. With Iceweasel, install the R-Kiosk plugin, but do not enable it yet.

3. Set Iceweasel's homepage to the page you want the kiosk to be at. Also run through Iceweasel and turn off features you don't want (tab bar, javascript, etc.) One thing to pay attention to is automatic updates of plugins. For a kiosk machine, especially one that is just displaying information, you do not want Iceweasel to take it upon itself to update the plugins. Turn this off.

8) Create an /etc/X11/xorg.conf file:

     Section "Serverflags"
        Option "DontVTSwitch"
     EndSection

This xorg.conf file disables the "ctrl+alt+Fn" key combinations used to switch to virtual terminals.

9) With Iceweasel, activate the R-Kiosk plugin. Then reboot. If you haven't restarted xorg after step 8, you can still switch to a virtual terminal to reboot. Otherwise, ssh in.

At this point you should have a fairly locked down browser session. Depending on what edits you made to .fluxbox/keys your users may have different options to deal with the browser. You should be able to access the box remotely via ssh as root for other management. Additional tweaking may be needed for your individual situation. For example, if you are using a large monitor over s-video, consider forcing the screen resolution in xorg.conf. You will probably want ntp installed, etc. Depends on your environment.

Edit:

With a kiosk machine, especially one connected to a large display (for advertising, etc.) there is a significant chance that the kiosk machine is rebooted when the display is powered off. Displays may be powered off at night to conserve power, and any maintenance on the kiosk machine is likely done at this time where a reboot cycle will not be visible to the public.

With the Squeeze kernel and KMS, if no display is detected you get no video. (I predict some frustrated traffic on web forums or e-mail lists when people start their desktop machines in the "wrong" order with Squeeze.) No video on a kiosk that has a main purpose of displaying video is an issue.

Luckily, the solution is quick and easy.

First, determine which video port you are using -- VGA, DVI, etc. and then tell the kernel to always turn that port on, even if the kernel does not detect a monitor attached to the port.

For example to turn on the VGA port edit /etc/default/grub and change

    GRUB_CMDLINE_LINUX_DEFAULT="quiet"

to

    GRUB_CMDLINE_LINUX_DEFAULT="quiet video=VGA-1:e"

The above example tells KMS to enable the VGA-1 port regardless of whether a display is detected on the port or not. The video= kernel argument has the syntax to set a specific display geometry and refresh rate, but the options are limited to what the BIOS will support. So I find it easier to just enable the port, and then create a stub xorg.conf file that uses a modes line in the display section to set the resolution you want. For example a kiosk I have is pushing video to a large screen TV at 1920x1080. That resolution doesn't work with the video= setting.

The video= commands aren't well documented, but there is some info here (which relates specifically to nouveau, but can be applied to other chipsets that KVM supports:)http://nouveau.freedesktop.org/wiki/KernelModeSetting

Edit: some clarifications in the instructions regarding editing files and settings.

Edit: When you update this system remotely, from time to time Iceweasel will pop up dialog boxes asking if you want the latest version of Try Again or R-Kiosk. For a kiosk with a mouse and keyboard, this isn't too much of a problem as you can just deal with the pop-ups locally. However for an advertising kiosk with no local keyboard or mouse this can be a problem. A tool that I use to get around this is the x11vnc package.

A) Install x11vnc

B) Create a wrapper script to start x11vnc for you. I called mine vnc_view.sh and put it in /usr/local/bin:

    #!/bin/bash
    sleep 60
    x11vnc -display :0 -env  FD_XDM=1 -auth guess -forever -passwd password &

The sleep command doesn't start x11vnc for a minute after boot, which gives xorg and fluxbox time to set up. If you leave this out, x11vnc will try to start before the xorg environment is ready. After the pause x11vnc is started in the background.

C) Call the wrapper script from rc.local, after you start fluxbox:

    /usr/local/bin/vnc_view.sh

You can now interact with the desktop using a vnc client to clear dialog boxes that appear after an iceweasel upgrade.

Good luck.

 

Posted by e5z8652 on Mon 23 Aug 2010 at 19:36
Tags: none.

Dear Googlebot:

I'm going through the process of upgrading Lenny machines to Squeeze after the freeze. After I'm done at work, only my pair of Squid servers will be Lenny. (They wait until Squeeze is stable.) While online I see a lot of evidence that people are having trouble with this upgrade, and thought I would share.

The key is getting the new kernel in place before you attempt the full upgrade.

This process works very smoothly, although it does require an extra reboot:

    sed -i s/lenny/squeeze/ /etc/apt/sources.list
    aptitude update
    aptitude install linux-image-2.6-686

Of course your kernel architecture might be different (amd64, etc.). Follow the prompts to install the kernel.

Aptitude will pull in perl, so you might want to include that on the command line to save a "y" or two.

(Note that I keep recommends turned off in apt.conf, so perl is the only major package pulled in on my systems. If you have recommends on you might get more.)

***reboot***

    aptitude full-upgrade

Note that doing the full-upgrade right away will leave you with a heck of a mess to untangle when apt tries to upgrade udev, but udev won't install on the running kernel. Then a whole set of key packages will fail to install, and aptitude will start finding crazy solutions to resolve the mess -- removing 3/4 of KDE while upgrading the rest, etc.

Much easier to just install the kernel and perl first and then let aptitude do it's thing.

 

Posted by e5z8652 on Tue 16 Feb 2010 at 22:16
Tags: none.
Say you have a MySQL table called "traffic" representing http requests through a web proxy with a date field (i.e. 2010-02-13) and a time field (i.e. 22:40:23) for each request. Then say you want to select records with a range using a datetime (i.e. 2010-02-13 22:40:23).

Let's say we want to see records for all traffic between 4:30 in the afternoon of January 1st and 5 in the afternoon on January 2nd, a 24 1/2 hour period.

If you write a select statement like this:

SELECT * FROM traffic WHERE date BETWEEN '2010-01-01' AND '2010-01-02' AND time BETWEEN '16:30:00' AND '17:00:00';
7573 rows in set (1.63 sec)



you will get all of the records from January 1st for the half hour between 16:30 and 17:00, and all of the records from January 2nd for the half hour between 16:30 and 17:00.

That's not what we wanted.

However, we can use a function to combine the date and time:

SELECT * FROM traffic WHERE DATE_ADD(date, INTERVAL time HOUR_SECOND) BETWEEN '2010-01-01 16:30:00' AND '2010-01-02 17:00:00';



The DATE_ADD function lets us turn the separate date and time fields into a single datetime field. Yay! It works great in testing with a small sample database, but there is one small caveat:

mysql> SELECT COUNT(*) FROM traffic;
+-----------+
| COUNT(*) |
+-----------+
| 186208916 |
+-----------+
1 row in set (0.00 sec)



That is 186 million rows in the table, representing proxy traffic for the past ten months or so. Going the DATE_ADD route means that MySQL will attempt the conversion on all 186 million rows of the table, and then compare the results to the BETWEEN statement. This takes a LONG TIME. Like a half hour on my hardware. Given that this SELECT statement is used in a cgi script that feeds a web page, a half hour is a bit long to ask the user to wait.

But we can fix this a little:

SELECT * FROM traffic WHERE date BETWEEN '2010-01-01' AND '2010-01-02' AND DATE_ADD(date, INTERVAL time HOUR_SECOND) BETWEEN '2010-01-01 16:30:00' AND '2010-01-02 17:30:00';
146948 rows in set (2.72 sec)



Now MySQL limits the results using the date value, and only does the calculation on the records for January 1st and January 2nd. Much faster at just under three seconds!

But is this really the most efficient way to do this? I can't change the database schema so the individual date and time fields must remain the way they are. What I'm looking for is a way to request a date/time range in a more efficient way than the one above. Any suggestions?

 

Posted by e5z8652 on Tue 17 Nov 2009 at 01:35
Tags: none.
A Lenny guest that went through a "P2V" process to a Hyper-V guest (really just mclone from the physical box to the virtual one over the wire) was gaining time at the rate of a few minutes per day. NTP could not keep up and so eventually rejected any sources.

Various combinations of clock=pit, nohz=on, etc. had no effect.

SuSE boxes on the same Hyper-V host were not having the same issue, and the only major difference I could find was the kernel version. I was running the stock 2.6.26 kernel so grabbed the 2.6.30 kernel from backports.

The 2.6.30 kernel from backports resolved it, and now NTP is happy.

Note that I didn't install the stock kernel in the virtual environment, so it could have been an initrd issue. No time to test that theory though.

 

Posted by e5z8652 on Thu 12 Nov 2009 at 09:06
Tags: none.
I have an old webcam, and recently dug it out and connected it. Found the modules for it and installed them. It used to work with Etch, now it doesn't. It suffers from bug 489244.

Bug 489244 was closed because the gspca modules were "removed from Debian."

And yet:

james@independence:~$ apt-cache policy gspca-modules-2.6-amd64
gspca-modules-2.6-amd64:
Installed: 2:2.6.26-6+lenny1
Candidate: 2:2.6.26-6+lenny1
Version table:
*** 2:2.6.26-6+lenny1 0
500 http://ftp.debian.org lenny/main Packages
100 /var/lib/dpkg/status

Somehow apt didn't get the word about the modules being "removed from Debian."

The bug was closed because the modules apparently come built in to the 2.6.28 kernel, but Lenny doesn't use that kernel.

I suppose it's time to move to Testing so my reality can match the bugreport reality?

 

Posted by e5z8652 on Tue 13 Oct 2009 at 01:25
Tags: none.
Has anyone set up an internal IM solution (Jabber?) connected to an SMS gateway that users can reach via cellphone?

I see the Jabber and SMS-Gateway packages and I'm sure I could muddle through, but any real world advice would be great.

This is for about 20-25 users behind a firewall that want to IM each other at the office, but also send/receive SMS messages to cell phones of people in the field.

 

Posted by e5z8652 on Wed 30 Sep 2009 at 00:02
Tags: none.
Somewhat by accident I fell on a squid configuration that will seamlessly proxy Windows XP workstations and Windows 7 workstations (both RC and gold) using NTLM negotiation.

This entry has been truncated read the full entry.

 

Posted by e5z8652 on Thu 16 Jul 2009 at 00:22
Tags: none.
This problem:

http://isc.sans.org/diary.html?storyid=6805

Is hard to solve in Lenny:

http://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=sun-java

When I asked about security updates for Lenny I was told to package it myself.

Hmm. While that *is* a solution, how many people get left behind?

Are there really so many changes between 6_12 and 6_14 that it would break a Lenny system?