Paul's Tech Blog: 2014

Monday 7 July 2014

Turning MP4 videos into something suitable for rubbish PCs on SharePoint

So the problem is you have a bunch of video recordings made with a tool such as Snaggit (http://www.techsmith.com/snagit.html) which are encoded in MP4 / H264.
Unfortunately they are just not small enough for our crappy SharePoint and some PCs don't have the tools to play them.

The solution - re-encode at a lower bitrate and convert them to flash video so they can be played inside an online player.

Snaggit default encodes at 512Kbps, drop this to 256Kbps for approximately half the file size and the quality still being good enough to see all the detail.

ffmpeg -i recording.mp4 -b:v 256K small-recording.mp4

Now put it in a flash video container.

ffmpeg -i small-recording.mp4 -c copy small-recording.flv

Flowplayer Flash is a good free online player. Extract the player into a subdirectory on your sharepoint site.

Create an html page to display it with your video. Here's the most basic one:
The lines in red are the ones to configure. Make sure you set the display size to match (or be half, quarter size etc) of the video to avoid black bars around the content.

<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">



    
    <script type="text/javascript" src="player/flowplayer-3.2.6.min.js"></script>

    
    <link rel="stylesheet" type="text/css" href="player/style.css">

    
    <title>ULS Training</title>

</head><body>

    <div id="page">

        <h1>A title for your video</h1>

        <p>A descriptive line of text about your video.</p>

        
        <a
            href="http://sharepoint/small-recording.flv"
            style="display:block;width:640px;height:385px"
            id="player">
        </a>

        
        <script>
            flowplayer("player", "player/flowplayer-3.2.7.swf", {
                clip: {
                    autoPlay: false,
                    autoBuffering: true,
                scaling: 'fit'
                }
            });

        </script>

Saturday 28 June 2014

Using winbind to authenticate to an active directory - Part 3

Having successfully set up my AD domain and got RHEL 6 clients authenticating to it, I'll now describe how to do the same thing for RHEL 5 clients.

You can read about the AD setup in Part 1 and the RHEL 6 configuration in Part 2.

I have performed a customized RHEL 5 installation, removing Desktop Environments, Applications, Printer Servers and reset the run level to 3.

yum install samba3x-winbind (you don't need samba for authentication)

Run authconfig-tui --enablemkhomedir to configure winbind, set the following options:
user information: use winbind
authentication: winbind
winbind domain: MY
security model: ads
winbind ads realm: MY.DOM
winbind domain controllers: dc.my.dom
template shell: /bin/bash

Don't click join domain at this stage.
When the wizard completes it will attempt to start winbind and fail. We haven't finished configuring yet so this is fine.
Remove the existing configuration databases, rm -f /var/lib/samba/*

Modify /etc/samba/smb.conf with the following options. This will map all AD users & groups into the range 100000-199999.

workgroup = MY
password server = dc1.my.dom
realm =MY.DOM
security = ads
idmap config * : backend = tdb
idmap config * : range = 200000-299999
idmap config my:backend = rid
idmap config my:range = 100000 - 199999
idmap config my:base_rid = 0
idmap uid = 100000-299999
idmap gid = 100000-299999

You can also set these useful options:

template shell = /bin/bash
winbind use default domain = true
winbind enum users = yes (let's you use getent passwd to see AD users)
winbind enum groups = yes (let's you use getent group to see AD groups)
winbind offline logon = true (cached users can log in when AD is unavailable. Very useful)

Now rerun authconfig-tui --enablemkhomedir and click join domain. Supply the AD domain password when prompted and the client will join the domain successfully. You will be able to see the client in the Windows ADUC tool

It should now start up properly:
chkconfig winbind on ; service winbind start

I'm not setting up centralised home directories so we'll use oddjobd to automatically create home directories when an AD user logs on for the first time to a client.

We'll set the home directories up in /home/MY and make them private. RHEL 6 uses oddjobd for this. RHEL 5 doesn't.

mkdir /home/MY
chmod 711 /home/MY
Modify /etc/pam.d/system-auth-ac to fix home dir permissions
session optional pam_mkhomedir.so umask=0077

Now restrict ssh access to users in the grp-linux-servers AD group.

Edit /etc/security/pam_winbind.conf
require_membership_of = grp-linux-servers

Finally restrict root access via sudo to those in the grp-root-access AD group

Edit /etc/sudoers
%grp-root-access ALL=(ALL) NOPASSWD: ALL

Some useful commands to check things are working:

wbinfo -u / wbinfo -g will pull a user and group list from the AD
wbinfo -D my / wbinfo --dc-info=my will put details of AD and associated DCs
getent passwd / getent group will show the client's passwd & group list including AD entries.

In Part 4 I'll describe how to achieve this on a Solaris 10 client. This is the most complex to set up as there is no out the box integration and it also requires additional freeware packages.

Using winbind to authenticate to an active directory - Part 2

Here I'll describe how to configure a RHEL 6 installation to authenticate using winbind to the AD my.dom set up in Part 1. RHEL 6 is the easiest client to configure as it has samba and winbind integration built into the OS.

I'll assume a basic server installation has been performed. You may need to add additional packages if you've gone with a minimal install.

yum install winbind (you don't need samba for authentication)

Run system-config-authentication or authconfig-tui to configure winbind, set the following options:

user account database: winbind
winbind domain: MY
security model: ads
winbind ads domain: MY.DOM
winbind domain controllers: dc.my.dom
template shell: /bin/bash
Advanced option: create home directories on first logon

Don't click join domain at this stage.
When the wizard completes it will attempt to start winbind and fail. We haven't finished configuring yet so this is fine.
Remove the existing configuration databases, rm -f /var/lib/samba/*

The key thing when integrating into a domain is to make sure the Unix UID / GID are consistent across all unix hosts. Winbind provides several mapping strategies for doing this. I'm using idmap_rid as it's simple to setup, doesn't require an external database and performs an algorithmic mapping from Windows SIDs to UID / GIDs

Modify /etc/samba/smb.conf with the following options. This will map all AD users & groups into the range 100000-199999.

workgroup = MY
password server = dc1.my.dom
realm =MY.DOM
security = ads
idmap config * : backend = tdb
idmap config * : range = 200000-299999
idmap config my:backend = rid
idmap config my:range = 100000 - 199999
idmap config my:base_rid = 0
idmap uid = 100000-299999
idmap gid = 100000-299999

You can also set these useful options:

template shell = /bin/bash
winbind use default domain = true
winbind enum users = yes (let's you use getent passwd to see AD users)
winbind enum groups = yes (let's you use getent group to see AD groups)
winbind offline logon = true (cached users can log in when AD is unavailable. Very useful)

Now rerun the authentication gui / tui and click join domain. Supply the AD domain password when prompted and the client will join the domain successfully. You will be able to see the client in the Windows ADUC tool

It should now start up properly:
chkconfig winbind on ; service winbind start

I'm not setting up centralised home directories so we'll use oddjobd to automatically create home directories when an AD user logs on for the first time to a client.

We'll set the home directories up in /home/MY and make them private:

mkdir /home/MY
chmod 711 /home/MY
Edit /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf
Change 2 umasks to -u 0077 (from 0002) to make home dirs private
service oddjobd restart

Now restrict ssh access to users in the grp-linux-servers AD group.

Edit /etc/security/pam_winbind.conf
require_membership_of = grp-linux-servers

Finally restrict root access via sudo to those in the grp-root-access AD group

Edit /etc/sudoers
%grp-root-access ALL=(ALL) NOPASSWD: ALL

Some useful commands to check things are working:

wbinfo -u / wbinfo -g will pull a user and group list from the AD
wbinfo -D my / wbinfo --dc-info=my will put details of AD and associated DCs
getent passwd / getent group will show the client's passwd & group list including AD entries.

In Part 3 I'll describe how to do the same thing for a RHEL 5 client. The principals are the same but RHEL 5 isn't so tightly integrated with windbind out the box so we have to do a little bit of extra work.

Using winbind to authenticate to an active directory - Part 1

Here I describe how to get various Unix clients to use winbind for authentication to a Windows AD Domain. For bonus points I will also describe how to make sudo use AD groups for controlling root access.

Setting Up The Domain

I am using a single Windows 2008 R2 standard edition install to host all AD functions.
Once installed and patched add the Active Directory Domain Services role which in turn will install the DNS server role if doing a single box install.

My example config:

FQDN: my.dom
Short domain name: my
Domain controller: dc.my.dom

Set up some groups to control access:

grp-linux-servers: Users in this group will be able to log onto linux hosts
grp-solaris-servers: Users in this group will be able to log onto solaris hosts
grp-root-access: Users in this group will be able to sudo to root

Create some example users to test it all out:

user1: member of grp-linux-servers - will only be able to log onto linux host
user2: member of grp-linux-servers, grp-solaris-servers - will be able to log onto linux & solaris hosts
user3: member of grp-linux-servers, grp-solaris-servers, grp-root-access - will be able to log onto linux & solaris hosts and sudo to root.

Finally add hostname A records into the DNS my.dom zone for your unix clients.

In part 2 I'll describe how to configure a RHEL 6 client to authenticate to this domain.

Tuesday 25 February 2014

Sudo : The basics

Basic structure of ACL entries for the sudoers file
Always use visudo to edit as it does syntax checking for you

Command aliases:
Cmnd_Alias DIAGS = /usr/sbin/tcpdump,/usr/sbin/ethtool

Network / host aliases:
Host_Alias LAN = 192.168.0.0/255.255.255.0

You can then allow a user to access these commands:

This will allow Paul to run tcpdump & ethtool from anywhere without reentering his password:
paul    ALL = NOPASSWD:DIAGS

Or you can restrict it to certain subnets:
paul    LAN = NOPASSWD:DIAGS

Omit the NOPASSWD parameter if you want Paul to reenter his password everytime he uses sudo.

If you want paul to be able to become root and do anything:
paul    ALL=(ALL)     NOPASSWD:ALL

Monday 6 January 2014

Replacing mirrored disks under Linux software RAID

So you've got a Linux server using software RAID with disk mirroring configured and when it's healthy it looks something like this:
# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [linear]
md3 : active raid1 sdb3[1] sda3[0]
949995648 blocks [2/2] [UU]

md2 : active raid1 sdb2[1] sda2[0]
8514368 blocks [2/2] [UU]

md1 : active raid1 sdb1[1] sda1[0]
8602688 blocks [2/2] [UU]

md4 : active raid1 sdb4[1] sda4[0]
9638912 blocks [2/2] [UU]

A disk goes pop, the system is still running but you need to replace the dead disk. After physically replacing the disk here's how to add it back to the raid configuration.

So we see that /dev/sda has died.

# cat /proc/mdstat

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [linear]

md3 : active raid1 sdb3[1]

949995648 blocks [2/1] [_U]

md2 : active raid1 sdb2[1]

8514368 blocks [2/1] [_U]

md1 : active raid1 sdb1[1]

8602688 blocks [2/1] [_U]

md4 : active raid1 sdb4[1]

9638912 blocks [2/1] [_U]

First copy the partition table from /dev/sdb onto /dev/sda:

# sfdisk -d /dev/sdb > /tmp/partitiontable

# sfdisk /dev/sda < /tmp/partitiontable

# sfdisk -l /dev/sda ; sfdisk -l /dev/sdb (They should now be identical)

Now add the partitions on /dev/sda back into the raid devices:

# mdadm -a /dev/md1 /dev/sda1

# mdadm -a /dev/md2 /dev/sda2

# mdadm -a /dev/md3 /dev/sda3

# mdadm -a /dev/md4 /dev/sda4

This will probably take some time so watch its' progress with:

# watch -n 5 cat /proc/mdstat

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [linear]

md3 : active raid1 sda3[2] sdb3[1]

949995648 blocks [2/1] [_U]

[>....................] recovery = 2.3% (21904000/949995648) finish=241.8min speed=63952K/sec

md2 : active raid1 sda2[0] sdb2[1]

8514368 blocks [2/2] [UU]

md1 : active raid1 sda1[0] sdb1[1]

8602688 blocks [2/2] [UU]

md4 : active raid1 sda4[2] sdb4[1]