Bug#791661: support for alternative passwd location (i.e. libnss-extrausers)

[Oliver Grawert]

hi,
On Fri, 18 Sep 2015 10:27:11 +0100 Dimitri John Ledkov
 wrote:
> Hello,
> 
> On 18 September 2015 at 08:13, Michael Vogt  wrote:
> > Hi,
> >
> > looks like the actual patches are missing for some reason. Attached
> > are the two patches that add support for libnss-extrausers.
> >
> 
> These patches look weird. Are these used to manipulate
> /var/lib/extrausers/* ? and why not use systemd-sysusers for that?
> 
> E.g. in clearlinux.org we have sysusers.d config files, which at
build
> time are used to generate {passwd,group,shadow,...}
> 
> The patches that we have for shadow (and i believe i have even
> published some of them) go further - that is they load information
> from both databases and allow manipulating it. Such that kvm group is
> defined in altfiles location, yet one can still add users to said
> group. In those patches a lookup is done to alternative location, and
> the entry is copied across into the writable /etc/group, if one wants
> custom user accounts to be added into a "system" group. There we use
> libnss-altfiles modules.
> 
> Could you please elaborate how this patch fits together and used in
> Ubuntu / snappy? If it's never interactive, why not use
> systemd-sysusers support then?

sadly this would not work with ubuntu-core/snappy since
passwd/group/shadow are read only inside a squashfs. they have to stay 
this way since the UIDs/GIDs will need to match for the lifetime of the
device (alternatively, to prevent filesystem permission problems we
would have to walk the whole file system to update IDs in the rw parts
every time the read only rootfs gets updated which is rather ... ugh
... ).

we add dynamic users and groups (even system ones) for additionally
installed snap packages that are not bound to the core snap squashfs to
the extrausers db dynamically.

the decision for extrausers was actually made based on the fact that
many internal debian servers seemed to use it for user mgmt back then,
so we had hope that added support for extrausers management in the
tools would be easily accepted and debian would benefit from it
alongside.

by the looks of it sysusers.d will not support adding non-system users
(which we would want) and will also not be able to keep the IDs locked
down (beyond the fact that the default password db files need to be rw)
so in the ubuntu snappy case this is a no-go.

ciao
oli

signature.asc
Description: This is a digitally signed message part

Bug#603920: shadow: securetty misses support for ttyO[0-3] devices

[Oliver Grawert]

Package: shadow
Severity: wishlist


as described in https://bugs.launchpad.net/bugs/512845 securetty.linux
misses support for serial ports on TI OMAP boards if the DMA-offloaded
driver instead of the default 8250 one is used for serial ports.

a fix can be found at
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/shadow/maverick/revision/36

-- System Information:
Debian Release: squeeze/sid
  APT prefers maverick-updates
  APT policy: (500, 'maverick-updates'), (500, 'maverick-security'),
(500, 'maverick')
Architecture: armel (armv7l)

Kernel: Linux 2.6.29-arm2-ac100 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


signature.asc
Description: This is a digitally signed message part

Bug#584508: [Pkg-ltsp-devel] Bug#584508: typo in in message

[Oliver Grawert]

hi,
Am Freitag, den 04.06.2010, 09:17 +0200 schrieb Ralf Treinen:
 Package: ltsp-client-core
 Version: 5.2.2-1
 Severity: minor
 
 Unpacking ltsp-client-core (from .../ltsp-client-core_5.2.2-1_amd64.deb) ...
 Aborting installation.
 The ltsp-client-core package provides the basic structure for an LTSP
 terminal. It cannot be installed on a regular machine.
while i can confirm my bad english grammar (i originally wrote these lines in 
ubuntu)

 
 an LISP = a LISP
i can not really agree with the solution... even though i'm slowly getting old 
and 
losing my hair and teeth its not that far that i'm starting to LISP :)

ciao
oli


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#575031: [Pkg-ltsp-devel] Bug#575031: creating virtual devices for fuse mounts?

[Oliver Grawert]

hi,
Am Freitag, den 23.04.2010, 13:08 -0700 schrieb Vagrant Cascadian:
 greetings.
 
 i'm trying to figure out how feasible it is to create some sort of virtual
 device for mountpoints mounted with fuse.
 
 i'm hoping this is the appropriate place for such a message... if not, please
 suggest a better place for such a question.
 
 as best i can figure out, KDE and LXDE use hal or udev/udisks properties for
 their file manager to recognize mounted devices or devices available for
 mounting.
 
 with fuse mounts, there is no associated device or udev event, as far as i can
 tell.
 
 in particular, i'm working with ltspfs, which is a remote fuse filesystem used
 for LTSP thin-clients. ltspfs on the client-side has udev rules to detect
 device insertion/removal, and then connects to the server that the user is
 logged into, and sets up a fuse mount server-side that the user then accesses.
 
 with GNOME, it recognizes mounts done in /media/, and so ltspfs mounts remote
 devices in /media and it gets recognized by GNOME's filemanager.  but KDE and
 LXDE don't handle mounts in /media in the same way, so ltspfs mounts that
 happen in /media and are not recognized by the filemanager (other than simply
 browsing to the mountpoint, like any other filesystem).
 
 a bug reported against ltspfs in debian:
 
   http://bugs.debian.org/575031
 
 is there some way to emulate a device, creating a virtual device in the
 hal/udev/udisks/devicekit namespace? a short-term approach that could be used,
 or a longer-term vision for how to handle these sorts of situations?
 
with hal it was possible to use hal-add-device and a script to create a
virtual device [1] but hal is dead beef upstream. take a look at what
the udisks package ships in /lib/udev/rules.d/, it should be possible to
write a rule that makes udisks create a virtual disk here.

ciao
oli

[1] http://people.canonical.com/~ogra/ltspfs-hal-root.png


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#539372: [Pkg-ltsp-devel] Bug#539372: ltsp-server: ltsp-build-client fails w/ 4 x W: Failure while configuring base packages

[Oliver Grawert]

hi,
Am Freitag, den 31.07.2009, 09:48 +0200 schrieb Andre Majorel:
 Package: ltsp-server
 Version: 5.1.76-1
 Severity: normal
 
 Dear ltsp-server maintainer,
 
 running
 
   ltsp-build-client --dist sid --base /opt/ltsp-5 \
 --mirror ftp://ftp.nerim.net/debian
 
 from a Debian testing i386 ends with this :
 
   [...]
   I: Configuring apt...
   W: Failure while configuring base packages.
   W: Failure while configuring base packages.
   W: Failure while configuring base packages.
   W: Failure while configuring base packages.
   W: Failure while configuring base packages.
   error: LTSP client installation ended abnormally
 
 Full log at :
 
   http://www.teaser.fr/~amajorel/bugs/ltsp-build-client-5.1.76-sid.out

this is not an ltsp bug, debootstrap is broken apparently ...

ciao
oli


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#537644: [Pkg-ltsp-devel] Bug#537644: Please denote 'openbsd-inetd | inet-superserver' to recommends

[Oliver Grawert]

hi,
On Mo, 2009-07-20 at 03:12 +0200, Daniel Baumann wrote:
 Package: ltsp-server-standalone
 Severity: normal
 
 Hi,
 
 as far as I know (but please correct me if I'm wrong),
 ltsp-server-standalone only depends on 'openbsd-inetd |
 inet-superserver' because of the tftp of choice.
sadly you are wrong, nbdswapd is running from ited as well (in debian
and ubuntu), and in ubuntu nbdrootd is also running from inetd.

while nbd swapping could be made optional in debian, ubuntu unlike
debian mounts its rootimage via nbd so there it is a hard dependency and
it would be nice to not introduce a dependency delta between the two
(indeed we will carry it if its unaviodable) since debian is well able
to use nbd root as well, it just doesnt default to it.

what was the reason to change the default mode ?
(i personaly prefer to run services on demand if they are only needed
temporarly and keep the resources clear when they are not needed)

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#535564: strace 4.5.18 fails to build on armel

[Oliver Grawert]

Package: strace
Version: 4.5.18
Severity: normal

due to an upstream change in linux/arm/syscallent.h strace fails to
build on armel with EABI enabled

https://bugs.launchpad.net/ubuntu/+source/strace/+bug/395077 has a
debdiff and a link to the openwrt.org git commit.

-- System Information:
Debian Release: squeeze/sid
  APT prefers karmic
  APT policy: (500, 'karmic')
Architecture: armel (armv7l)

Kernel: Linux 2.6.26-394-gf56b72e (PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


signature.asc
Description: This is a digitally signed message part

Bug#456327: [Pkg-ltsp-devel] Bug#456327: replace udevinfo call with udevadm

[Oliver Grawert]

hi,

udev (117-1) hardy; urgency=low
 .
   * New upstream release:
 - udev ancillary tools merged into a single udevadm binary.

...


upstream changed it recently ... debian will have to do that switch at
some point as well i guess ...

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#459369: [Pkg-ltsp-devel] Bug#459369: ltspfs: patch for automatically creating icons on the kde desktop

[Oliver Grawert]

hi,
On Sa, 2008-01-05 at 23:38 +0100, Klaus Ade Johnstad wrote:
 Package: ltspfs
 Version: 0.4.3+debian2+0.edu.0.etch.1
 Severity: normal
 
 The attached patch creates corresponding icons on the users kde desktop when 
 they insert a removable device.
 
could you make that depend on a lts.conf variable please, we generally
consider it evil behavior in ubuntu to create symlinks in users
homedirs ...

(beyond that i'd rather like to see it properly fixed on a lower lavyer
rather than worked around in such a way but i see the need for kde ...)

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#454478: [Pkg-ltsp-devel] Bug#454478: ltspfsd should not recommends ldm

[Oliver Grawert]

hi,
On Do, 2007-12-06 at 14:47 -0800, [EMAIL PROTECTED] wrote:

 i'd be open to hearing more on the matter, particularly use cases where
 the current layout doesn't work.
you mean more like: ltspfsd is a no-op without the xprop set by ldm or
that we install our rc scripts into /usr/share/ldm/rc.d ? 
or the fact that even if the udev scripts are harmless, making it
possible to install them in a normal system which is more vulnerable to
security leaks forces us to put more ressources into security ? 
it think the recommends is totally justified here, at the current state
ltspfsd wont work at all without ldm installed i'd even turn it into a
dependency ... 
the split would allow developers to develop their own solutions without
the udev and ldm overhead installed using ltspfsd-core, while i dont see
a reason to enable normal users to install a non-functional ltspfsd
package ...

note that in ubuntu ltspfsd even depends on ltsp-client to prevent the
udev scripts being installed in normal systems (no matter if they are
harmful or not, i just dont want them there since nobody ever tested how
or if they interfere with existing rules and you can get unpredictable
results)

imho the split is a good compromise for us all, i could keep the dep
tree in place i want, you could install without the metapackage if you
urgently want the scripts in normal workstations, mario could work with
only the core package and users would not be able to break ther systems
accidentially.

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#454478: [Pkg-ltsp-devel] Bug#454478: ltspfsd should not recommends ldm

[Oliver Grawert]

hi,
On Mi, 2007-12-05 at 16:09 +0100, Mario Izquierdo (mariodebian) wrote:
 Package: ltspfsd
 Version: 0.5+debian1
 Severity: normal
 
 lstpfsd is used only in LTSP chroot and Recomends ldm package.
 
 I'm working on new thin client implementation and try to put into Debian
 officially. I don't need ldm login manager, only ltspfsd daemon.
 
 Since some time, apt recommended packages are installed and
 without extra configuration can install ltspfsd without ldm.
well, i think ltspfsd will not work without the proper mcookie thats set
by ldm anymore you will need any similar implementation in whatever you
use instead, between the 4 and 5 series a lot of security changes were
made that you will need to take into account, ldm brings parts of these
in. 
i dont see a reason why we shouldnt split the binary into ltspfsd-core
and ltspfsd-scripts and an ltspfsd metapackage that depends on both. 

that way you could use the ltspfsd-core package which contains only the
binary. it has the advantage that the scripts can be arch: all

any opinions ? 

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#244490: ubuntu xaos xdg compliance patch (including icon)

[Oliver Grawert]

hi,

you probably might want to take a look at the icon and .desktop file
patch i created for xaos in edubuntu. it can be found under:
http://people.ubuntu.com/~ogra/xaos/xaos_xdg_compliance.patch

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#317888: please reopen, apprently it was reintroduced in 2.9.x

[Oliver Grawert]

hi,

as ubuntu bug https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/121827
states, the inetd code was disabled in the source. This is pretty fatal
for us at ltsp.org since we just switched to base everything on nbd
exported squashfs files. 
As long as we dont have a proper connection based timeout mechanism
(currently only traffic is checked for, which is pretty odd if you
have / on nbd and dont read from it constantly like ltsp clients do
after they started up everything), we're bound to rely on tcpd's
keepalive settings which we get through running nbd-server through an
inetd wrapper.

please reintroduce the inetd option.

ciao
oli


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#421762: [Pkg-ltsp-devel] Bug#421762: ltsp-client-builder: Fail to set correct default X keyboard layout

[Oliver Grawert]

hi,
Am Dienstag, den 01.05.2007, 12:51 +0200 schrieb Petter Reinholdtsen:
 Package: ltsp-client-builder
 Version: 0.99debian11
 
 When using the ltsp-client-builder udeb to install the LTSP chroot
 from within debian-installer, the default X keyboard layout used by
 the thin client is not inherited from the keyboard layout setting
 selected in debian-installer.  In the Debian Edu subproject, we want
 the keyboard layout selected during installation to take effect also
 in LTSP, to reduce the amount of configuration required before the
 system is ready to use.
as discussed on IRC it would be preferable to set such things from an
ltsp-build-client plugin, so eople not installing through d-i get the
benefit as well. i suggest to have a look at the
server/plugins/ltsp-build-client/Ubuntu/025-locales plugin we use in
feisty, probaly you can just add some bits to the debian equivalent.

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#410485: [Pkg-ltsp-devel] Bug#410485: ltsp-server: remote syslogging on ltsp clients is broken

[Oliver Grawert]

hi,
On Sa, 2007-02-10 at 16:53 -0800, Vagrant Cascadian wrote:
 === modified file 
 'server/plugins/ltsp-build-client/Debian/000-basic-configuration'
 --- server/plugins/ltsp-build-client/Debian/000-basic-configuration   
 2007-01-11 06:53:01 +
 +++ server/plugins/ltsp-build-client/Debian/000-basic-configuration   
 2007-02-11 00:36:09 +
hmm, we should find an automatic notification system of some kind, this
change is included in ubuntu in 

server/plugins/ltsp-build-client/Ubuntu/000-basic-configuration

since syslog was patched to accept /etc/ltsp/syslogd to override the
default (since edgy), we install a syslogd  file that enables remote
logging with our ltsp-server package in this path. that doesnt give you
the guarantee that syslogging is on if you use a differnt server, but
for a default it makes still sense as you will fix the problem for a
majority of users that just uses the package without tweaks.

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#389276: please reopen and mark as grave

[Oliver Grawert]

hi,

if you dont use a preseed file for ltsp at all, your sources list will
have:

deb none etch/updates main restricted

that breaks CD installs completely (at least in ubuntu) i dont know if
etch uses any preseeding by default (it shouldnt on a plain debian CD to
give the admin the opportunity to override)

from --security-mirror none was removed for now from ubuntus
ltsp-client-builder udeb ...
i think the manage-mirror plugin should get pattern matching to ignore
the entry if set to none.

ciao
oli



signature.asc
Description: This is a digitally signed message part

Bug#398630: [Pkg-ltsp-devel] Bug#398630: ltsp-client: preinst fails

[Oliver Grawert]

hi,
Am Dienstag, den 14.11.2006, 19:47 +0100 schrieb Lucas Nussbaum:
  it requires the presence of an /etc/ltsp_chroot file in order to
  install. this is a safety precaution to ensure that ltsp-client is being
  in an LTSP environment and not on the regular system, as the ltsp-client
  init scripts do things that most users would not want on a regular
  system.
  
  though, now that you've brought it up, it might be better for the init
  scripts to check for the presence of /etc/ltsp_chroot rather than
  preinst.
 
 preinst or postinst looks fine, but please output an error message
 explaining exactly what you explained in that mail, instead of just
 dying silently :-)

erm, in ubuntu it presents you a debconf warning with the text vagrant
pointed out from the package description and fails gracefully, i dont
know why it doesnt do that in debian, did you by chance play with the
debconf priorities ?

ciao
oli


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#390722: [Pkg-ltsp-devel] Bug#390722: ltsp-client-builder have the wrong priorit, wont be run from debian installer

[Oliver Grawert]

hi,
Am Montag, den 02.10.2006, 20:21 +0200 schrieb Ronny Aasen:
 Package: ltsp-client-builder
 Version: 0.99debian3
 
 ltsp-client-builder should run after pkgsel, before finish install.
 with  ltsp-client-builder haveing a priority of 69, it wont be selected 
 in the meny and wont run unless you manualy select it. In effect it wont 
 run. And the ltsp chroot will not be created.  ltsp-client-builder 
 should have a priority between 71 and 78.
 
 In addition the file
 http://d-i.alioth.debian.org/svn/debian-installer/installer/doc/devel/menu-item-numbers.txt
 state that priorities should be assigned by debian-boot, and not picked 
 at random.
 
 I have tested a local build ltsp with priority 73, and that was selected 
 as expected.
 Would debian-boot please assign a priority to ltsp-client-builder ?
 somewhere between pkgsel and finish-install
note that ltsp-client-buoilder was written for edubuntu in the
beginning, we run it from the edubuntu preseed file in the isntaller and
didnt want it to run on ubuntu, kubuntu and xubuntu installs unless
manually selected from the menu in expert mode ... (users usually dont
see the menu in a normal install in any *buntu variant

since you likely dont want to run it in a normal debian install i'd
suggest doing it in a similar way in debian-edu or skolelinux, so that
you are still able to include it as an optional item in normal debian
installs.

ciao
oli


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#377174: FTBFS with GCC 4.2: C/C++ linkage declarations conflict

[Oliver Grawert]

hi,

i added a fix in the ubuntu package, you might be intrested ... 

kino (0.90-1ubuntu2) edgy; urgency=low

  * add 70_fix_builderror to fix ftbfs (debian bug #377174)

-- Oliver Grawert [EMAIL PROTECTED]  Sun, 16 Jul 2006 18:38:40 +0200


#! /bin/sh /usr/share/dpatch/dpatch-run
## 70_fix_builderror.dpatch by  [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.

@DPATCH@
diff -urNad kino-0.90~/src/kino_common.h kino-0.90/src/kino_common.h
--- kino-0.90~/src/kino_common.h2006-02-07 08:10:09.0
+0100
+++ kino-0.90/src/kino_common.h 2006-07-16 19:14:53.0 +0200
@@ -315,7 +315,10 @@
void fetchProjectMetadata( const std::string projectKey );
};

-// Yucky global reference
-extern KinoCommon *common;
+extern C 
+{
+   // Yucky global reference
+   extern KinoCommon *common;
+};

#endif



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#217571: mediawiki packages

[Oliver Grawert]

hi,
Am Montag, den 25.07.2005, 16:14 +0200 schrieb Romain Beauxis:
 Le Lundi 25 Juillet 2005 16:05, Andreas Tille a écrit :
  On Mon, 25 Jul 2005, [ISO-8859-1] Oliver Grawert wrote:
   i made mediawiki package we'll use for ubuntu, since #276057 seems to
   have made very slow progress and i need the package in ubuntu (for
   edubuntu) before Aug 11th ...
 
  Well, I used the packages of Duck at
 
http://debian.duckcorp.org/
 
  without any problem.
 
   feel free to grab them, they are (indeed) depending on ubuntu packages,
   if you got any questions feel also free to bug me :)
  
   the packages can be found here:
   http://www.grawert.net/mediawiki/
 
 There are some updated packages available at
   http://www.cti.ecp.fr/~beauxir5/debian
 
 They are Duck's packages updated to last upstream release, with some 
 important 
 changes and corrections about files location and configuration messages.
 
 Feel free to send back any remark..
wow, thats nice !!

why is there no info on the ITP bug about them ? i woldnt even have
started to package them if i knew about that ;) indeed its my biggest
interest (as the one of every ubuntu maintainer) not to move to far away
from debian and do the work twice ;) 

we're also moving towards php5 for breezy so i can probably provide some
patches aginst them if debian does this move too in the future.

thanks again...

ciao
oli


signature.asc
Description: This is a digitally signed message part

Bug#300962: xscreensaver: Add pretty lock dialogue from Ubuntu?

[Oliver Grawert]

hi,
Am Mittwoch, den 23.03.2005, 00:35 +0100 schrieb Josselin Mouette:
 Le mardi 22 mars 2005  23:47 +0100, Sven Arvidsson a crit :
  Package: xscreensaver
  Version: 4.21-1
  Severity: wishlist

 I'm currently working on a Xft version of that dialog box, but these are
 quite important changes, and upstream disagrees with them. I'm against
 using Ubuntu's patches directly, as the result isn't configurable at all
 and it doesn't have the new login button.

i'm really happy to see that so many people like my little hack, but i'd
like to point out that its really only a hack and isnt planned to
survive the next release in ubuntu, its an interim solution for hoary
until a safe implementation for gnome is found, since thats the desired
way to go for us.

it seems Josselin had the same idea i had, since all i did was to pick a
themeing patch from Alan Swanson to make xpm themeing possible and to
change all drawing and font code to use the xft equivalent, so the lock
code stayed as it is and the possible security issues are kept at a
minimum.

ubuntu uses version 4.16, i'm not even sure it would apply to 4.21
without bigger changes, since i dont know what code changed between
these versions.

everything is hardcoded and not configurable but i'll send an additional
mail these days with th completed patch attached (its not completely
done yet and still has some rough edges), its probably a good base for
ideas for a new implementation, but i fully agree with Josselin that a
configurable variant and even a new login button would be better.

i for myself decided to wait for the gnome screensaver and not to put
more work into this hack then absolutely necessary for ubuntu hoary.

ciao
oli




signature.asc
Description: This is a digitally signed message part