Posts

Posted on

read only access to a webdav share using apache2 mod_dav

did you know you can configure mod_dav to allow read-only access to your webdav share (apart from the usual read-write access)? all you need is set “Options Indexes”, point your browser to the webdav url and enter your credentials. basically, i have the following mod_dav configuration[1]:

BrowserMatch “^WebDAVFS/1.[012]” redirect-carefully
BrowserMatch “Microsoft Data Access Internet Publishing Provider” redirect-carefully
BrowserMatch “Microsoft-WebDAV-MiniRedir/5.1.2600” redirect-carefully
BrowserMatch “^WebDrive” redirect-carefully
BrowserMatch “^WebDAVFS” redirect-carefully

LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
DavLockDB /var/lib/dav/lockdb

DavMinTimeout 600
<Directory /path/to/the/dav>
Options Indexes
Dav On
AuthType Basic
AuthName “Please enter your webshare credentials”
AuthUserFile /path/to/the/passwordfile
Require user johndoe
</Directory>

i had to remove <Limit> restrictions as basic auth didn’t work with it for some reason. configuring a share that can be both accessed (read-write) using samba/smb/cifs and webdav is a bit more tricky and depends on which linux distribution you use. in a nutshell, you need to fiddle with directory permissions (especially the “sgid – set group id” bit) and figure out which setting works best (and the most securely) for you.

note that for security reasons, you should only allow encrypted http access (https using tls/ssl) to your share (see the <Redirect> option for example).

[1] in gentoo, edit /etc/apache2/conf/modules.d/45_mod_dav.conf

(thanks to flo for the tip)

Posted on

nload – network bandwith monitor for the console

nload, a decent network bandwith monitor for the linux console (you can thus use it to quickly monitor the available bandwidth on your remote linux server):

www.roland-riegel.de – nload: monitor network traffic and bandwidth usage

# emerge nload (surprise, surprise ;)

usage (for example):

# nload -i 2000 -o 400

(where 2000 is the [i]ncoming/downstream and 400 the [o]utgoing/upstream bandwith of my server in kbit/s)

(note that it doesn’t brew coffee, though ;)

(kudos to Crypto from #gentoo for the hint)

Posted on

Sightseeing pictures around Schwyz, the Vierwaldstättersee and Zug

As the pictures of last Friday’s private sightseeing tour in Schwyz and Zug turned out surprisingly well (considering that I shot them rather carelessly using my compact digicam, i.e. amateur gear ;), I decided to make them public. I’ve removed any pictures with close-ups of people, therefore you may freely use these pictures for any purpose (credits welcome, however):

Some pictures I like particularly (more or less in chronological order; unfortunately I forgot to take a picture of the Kloster Ingenbohl SZ):

The Kollegium Schwyz (where my father went to school)

The chapel inside the Kollegium (where he had to celebrate high mass and sing in the choir way too often, as he told me ;)

The bottom of the lectern in the church of Schwyz (where he had to celebrate high mass way too often, again ;), showing the ‘Aufdermaur’ emblem (my grandma R.I.P. was an Aufdermaur)

The Ratshaus in Schwyz (SZ)

The Erlenkapelle (first built in 1485) in Ibach/Schwyz (my uncle wrote a not-yet-published chronicle about it I recently typewrote for him)

Some pics of the dock and the lakeside in Ingenbohl-Brunnen (where I happen to be citizen) at the border of the Vierwaldstättersee.

Note that there’s even a little bunker right at the foot of the famous Rütliwiese (where “Switzerland” was founded on August 1, 1291 AD according to the saga ;)

The rocky coastline of the Vierwaldstättersee (a rather deep lake with a depth of 214 m) (BTW Why go to Krabi if you can have rocky coasts in Switzerland? ;))

Bauen, a tiny village at the border of the Vierwaldstättersee where palms grow (due to the very mild climate).

Windsurfers in Flüelen (UR). The water was rather chilly despite of the sunny weather (hence the neoprene suits ;). Obviously nice winds nonetheless :)

The famous/notorious wall painting by Ferdinand Gehr (the people jokingly used to call the painted angels “Spiegeleier Gottes” [God’s fried eggs] due to their somewhat strange/simple shape reminding of fried eggs ;) in the Bruder Klaus church in Oberwil (ZG)

The lakeside and some cafes with a nice view on the lake in Zug (ZG)

Posted on

Weblogs and PR

“Weblogs werden in Zukunft als Werkzeug eine wichtige Rolle in PR-Kampagnen spielen”, says Stephan Oehen of Klaus J. Stöhlker AG (PDF). Therefore they launched their own Weblog in March/April, 2005.

As a professional PR agency with self acclaimed fast decision making, it’s pretty astonishing it took them that long to come to this conclusion.

So, know who you choose as your consultant.

Posted on

KURSBUCH Glockenstrauch by Salome Rebekka In-Albon

Yesterday evening reminded me of how multifarious life is – much more than just facts and figures we tend to be snowed under with – and the importance and elegance of art. Splendid finish and promising beginning. A milestone. A rarity so far, watch out for the “KURSBUCH Glockenstrauch” by Salome Rebekka In-Albon:

Von den Wellen hin und her geschmissen schaukelte ich im Meer, von Land weit und breit keine Spur. Nicht mit einem Horn, nicht mit einer Leuchtpistole, mit einem leisen Wort nur, war ich schlagartig umgeben von Menschen. An Ort und Stelle, jawohl, mitten auf dem Meer, zimmerten sie in geschickter Teamarbeit ein solides Schiff. Durch Böen, begleitet von Wolkenbrüchen, von Sonnenstrahlen, mal Tiefgang, mal weniger, volle Kraft voraus, grobe und glatte See, aber zielstrebig dem Land entgegen. Zeit genug, ein Kursbuch zu führen.

As a spark, I’m proud of and thankful for being part of this great work and endeavor. Salutations to the “crew” and associates:

Salome (The captain), Johanna, Clemens, Megy, Markus, Toni, Max, Yvonne, Nora, Nicolas, Gertrud, Heidi, Magdalena and all those who couldn’t be there.

Spring, a wonderful time for art to blossom.

Posted on

monotone: a BitKeeper replacement?

As Linus Torvalds mentioned it as the most viable BitKeeper replacement, monotone: distributed version control is on my watchlist now (and it should be on yours too, eventually ;).

I’ve been using subversion/svn for a while now (BTW if you use it, choose FSFS for storage type and DAV for connectivity). It’s pretty okay (way better than CVS, at least) as long as you’re working online and the only one accessing the repository ;) For distributed development (such as with the Linux kernel) it’s less suitable though. Particularly merging conflicting revisions kind of “sucks”. Monotone promises to bring improvements in this field (monotone FAQ):

How do you merge versions?

The merging system is based on a pair of 3-way merges: one set-oriented one at the changeset level to resolve differences in tree layout, and one line-oriented one at the file level, to resolve differences in concurrent edits to the same file. If either of these fail, they are passed off to a user-provided hook function, which invokes emacs ediff mode by default (but can be overridden).

It is important to note that a 3-way merge is not the same as simply “applying patches” in one order or another: we locate the least common ancestor of the merged children in our ancestry graph, calculate the edits on the left and right edges, adjust the right edge’s edit coordinates based on the left edge’s edits, and only then do we concatenate the left and right edges (ignoring identical changes, and rejecting conflicting ones).

Why not use more “sophisticated” merge algorithms, as
in Codeville, Darcs, or
Arch?

A few reasons:

  • We don’t see how Codeville’s algorithm achieves anything beyond
    what we currently do, though we’ll happily listen to explanations.
  • Darcs algorithm is based on patch commuting, which requires a
    fundamentally different representation of versions than ours.
  • Arch’s merges are based on applying patches in various orders.
    While better suited to cherry-picking, only one of them (star-merge)
    seems to provide a 3-way merge; the other two are strictly weaker.
  • In general, we’re afraid of hitting patents. We don’t know exactly what’s
    patented in this field, but so far the 3-way merge has served well.

If you find a better, free merge operator, please let us know!

Hopefully, there will be more choice regarding monotone’s frontends and IDE integration soon.

BitKeeper would be the VCS of choice for me. Unfortunately, it will be closed source software exclusively soon. Due to BK’s high price tag, a commercial license (or leasing) of BK is not an option at the moment.

BTW. Surprisingly, there’s a whole bunch of other interesting VCS projects (most of which I didn’t know).

UPDATES:
1. monotone is available in Gentoo’s Portage tree, ready to be installed (IOW stable) :)
2. svk looks interesting too (particularly if you use svn already). Gentoo ebuilds for svk are masked currently.

Posted on

exec-shield again

as ingo restarted to publish plain exec-shield patches, i decided to apply his patch again. exec-shield-nx-2.6.11-A8 works nicely with kernel 2.6.11.6. there’s just a minor reject for the makefile:

– EXTRAVERSION =
+ EXTRAVERSION = -exec-shield

either patch the patch or change EXTRAVERSION from “.6” to “.6-exec-shield” manually.

nice document about exec-shield (among others): New Security Enhancements in Red Hat Enterprise Linux v.3, update 3 (PDF). another nice document: Security Enhancements in Red Hat Enterprise Linux (beside SELinux) (PDF). it also features a cool shell script – which is protected by copyright laws (and strict pdf drm settings) unfortunately.

NOTE TO SELF: check for compatibility with vms (jvm, mono). might break a couple of things.

Posted on

Distributed computation – OpenMosix – Migshm

Need to take a look at Migshm – A MAASK group DSM patch for openMosix (Gentoo patches). Might be useful for transparently distributing Mono/Java apps to leverage the computing power of many nodes in a LAN. Note that only Java apps running on JVMs using green threads are distributable with default OpenMosix. Mono apps aren’t distributable at all as the VM only uses native threads so far (I was told; not verified so far).

I should also re-enable distcc in order to better leverage available computing power.

Posted on

lim[t=0->inf](The Joel Test(t)) = 12 ?

An old “acquaintance”: The Joel Test: 12 Steps to Better Code

Just stumbled on it again. I don’t agree with all of the points[1], but it can’t hurt to check them in everyday life from time to time.

[1] 9 wrongly neglects budget restrictions, 11 wrongly discriminates people with a deep understanding of CS/IT but little practice in language XY, 12 a) not everybody has a bunch of people at hand for usability testing b) people tend to treat things as “well usable” if it feels or looks familiar even if they’re actually accustomed to very bad habits in regard to usability.