Thomas Sailer

Show:

What's happening?

  • Comment: sgrp/pgrp features

    Yes, thanks, that suits me fine.

    2008-06-19 10:25:35 UTC in pam_mount module

  • Comment: Problem with volume sgrp and winbind

    I've tried 0.41, and sgrp="xx" now indeed works, thanks. I'm still having problems with XXxx, as that still matches users who are not members of xx or XX.

    2008-06-19 10:22:26 UTC in pam_mount module

  • Comment: Problem with volume sgrp and winbind

    It works now for me with pam_mount 0.40. But unfortunately sgrp="xx" does not work anymore, both and xx matches always, regardless of the user being member of that group or not...

    2008-06-13 17:33:35 UTC in pam_mount module

  • Comment: sgrp/pgrp features

    A valid concern, I don't think you want a full fledged expression tree syntax... How about:

    2008-05-27 19:11:22 UTC in pam_mount module

  • Comment: sgrp/pgrp features

    Yes, that's what I do now, and it works. It would simply be nice if I didn't have to duplicate ~20 volumes.

    2008-05-27 09:10:12 UTC in pam_mount module

  • sgrp/pgrp features

    It would be great if multiple groups could be specified for sgrp, and a user would match if it is member of any (or multiple) of the specified groups. Also, it would be great if case insensitive match could be specified for sgrp / pgrp. Under windows, this information is case insensitive, and winbind sometimes returns group names as "domänen-benutzer", sometimes as "Domänen-Benutzer".

    2008-05-27 08:36:18 UTC in pam_mount module

  • Problem with volume sgrp and winbind

    I'm using pam_mount to automount some windows shares whenever a user logs in. I'm using winbind with "winbind use default domain = true", so users can log in using "user" as user name (in addition to "DOMAIN\user"). However, getgrent returns only "DOMAIN\user" as member names in gr_mem. The attached patch, which I'm using successfully, adds another method to determine user group membership...

    2008-05-27 08:33:15 UTC in pam_mount module

  • Path name problems when opening vmap0 (v0noa) on Linux

    I'm having problems opening the north american part of vector map level 0 on Linux with the current ogdi version (as packaged by fedora). It tries to open paths like this: /tmp/v0noa/vmaplv0/noamer/hydro/A\L/edx which obviously does not work, because \ is used as path separator, and because the cases of A and L is not correct. The attached patch fixes the problem for me. It tries to...

    2008-01-07 23:52:47 UTC in Open Geospatial Data Interface

  • vector image file output

    vector image files have the advantage that they can be scaled arbitrarily without becoming either big or pixelated. This patch implements a CairoMM based rendering backend. The patched drawtiming then offers output to postscript, pdf and svg files in addition to the Magick++ backend pixel files.

    2007-07-07 10:02:28 UTC in drawtiming

  • Comment: High levels of zooming can cause strange results

    The patch I've just submitted fixes this problem for me... Tom.

    2007-05-17 19:53:34 UTC in PlotMM

About Me

  • 2004-02-16 (6 years ago)
  • 976704
  • tsailer (My Site)
  • Thomas Sailer

Send me a message