Alexander Larsson | 11 Nov 17:58 2005
Picon

sabayon LDAP support

I just commited an initial version of LDAP support to sabayon, and I'm
looking for comments. See 
http://mail.gnome.org/archives/sabayon-list/2005-November/msg00001.html
for my request for comments.

I'm sending this to the deployment list in hope that there are people
with good knowledge of deploying things in networks using LDAP. If you
have, please take a look at it and comment.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl <at> redhat.com    alla <at> lysator.liu.se 
He's a benighted day-dreaming jungle king living undercover at Ringling Bros. 
Circus. She's a ditzy cat-loving bounty hunter on her way to prison for a 
murder she didn't commit. They fight crime! 

Perceived Software Quality Survey (PESQUS) for GNOME

Dear GNOME Users and Developers:

We are conducting empirical research on the quality and interface aspects of 
various open-source and proprietary software. Therefore, we are investigating 
the quality of the GNOME desktop software as perceived by its users. For this 
purpose, we have created a short survey.  We would highly appreciate it if 
you could follow the link below and fill out this survey:

http://www.umbc.edu/hase/gnome-pesqus-survey.html

The developers who use GNOME during their daily computer operations can 
respond too.

Many thanks for your help.

HASE
HUMAN ASPECTS of SOFTWARE ENGINEERING
INFORMATION SYSTEMS DEPARTMENT, UMBC
hase <at> umbc.edu

All HASE surveys are reviewed and approved by the Institutional Review Board 
of UMBC.

P.S. Apologies if you received more than one copies.
Sayamindu Dasgupta | 18 Jun 16:47 2004

Questions on running GNOME over LTSP

Hello all,
We are trying to implement a LTSP setup for some local schools
(madrasah[1] for girls), and currently we are in the testing phase. 

Recently, some of out testers were complaining that the icons on their
desktops were looking weird (just a blank paper), and after some
investigation, I found that those testers, instead of logging out, were
simply powering off their terminals. As a result, gnome-settings-daemon
and a few other stuff kept on running at the server, and when they
relogged in, their desktop icons were borked.

Is there any way to avoid this (maybe some kind of time out value or
something for gnome-settings-daemon and friends)??
Of course, one can simply ask the users *not* to switch off their
terminals like that, but the places where the actual thing is going to
be implemented have frequent power cuts, and I don't think we will be
able to have UPS-es, etc for the terminals. In case of power cuts, we
will be facing similar issues. And at least in the initial stages, it
would be a bit too much to expect the teachers/instructors (who are not
very well acquainted with computers, especially *nix like systems)  to
grep through ps and kill the running processes by hand :-S
.
Any help in this area will be highly appreciated.
-thanks-
-sdg-


[1] http://en.wikipedia.org/wiki/Madrasah
--

-- 
Sayamindu Dasgupta
(Continue reading)

Terje J. Hanssen | 2 Feb 03:32 2004
Picon

Gnome/Linux login/session host for a Solaris appserver

To offload an older Sun/Solaris CAD application server from running also
CDE sessions for networked XDMCP clients(diskless clients, X terminal),
I have started to introduce a Sun Java Desktop System workstation as a
Gnome login&session host/server.

That is, the X station/terminal query the SJDS host for GDM
login&session and from there have to get the Solaris appserver to run
the CAD application as execution host. 

It was quite easy to enable XDMCP on SJDS/Gnome.
The sun XDMCP client loads its X server and get remote GDM login with
the following entry:
/usr/openwin/bin/Xsun -nobanner -query SJDShost

My questions are:

1) Does Gnome (like xdm and CDE) use Xaccess to restrict which XDMCP
clients are allowed to connect, or are there other ways to do it?

2) How to include the SJDS host as fontserver in the query?

3) In addition I wish install the lacking themes Bright and Esco, which
are suggested for 8 bit color support.

Kind regards,
Terje J. Hanssen
Raucci, Giacomo P. "Jack" | 28 Jan 14:23 2004

Deleting an Item [SHADE] from a Menu from the Panel Menu

I am currently working at Kennedy Space Center on Shuttle upgrades and
we plan to use GNOME as our Desktop on top of Solaris OS; however, we are learning its capabilities.
We need to know now to disable certain features for the Shuttle Operations guys,
one of these features is the SHADE feature under the Panel Menu.
The GNOME 2.0 Solaris System Admin Guide indicates how to edit/delete
menu items from an menu; however, it does not work for menu items originating
from the panel; e.g. the SHADE menu item since selecting the right-mouse
button brings up another set of commands.
Being a new user to your web-site,  it was recommended that I post to this forum,
please let me know otherwise.

thanks, Jack Raucci

Havoc Pennington | 14 Dec 04:17 2003
Picon

add-applets-to-panel script

Hi,

Glynn mentioned this script written by Mark in his web log:

http://www.gnome.org/~gman/mark-applet-script

might be useful as a demo of how to add a panel applet from a script.

Havoc
Matthew Walburn | 10 Dec 20:46 2003
Picon

Gnome 2.2 /RHEL 3 Default Panel Question

Hi there, I was wondering if anyone here could point me to some 
documentation or a howto on how to add the Terminal launcher (or a 
custom launcher) onto the panel so that any new user will also receive 
the customization. I have looked at the GNOME 2.2 admin guide over and 
over, but I still can't get it happening.

Any help would be so appreciated.

Thanks!

-Matthew

--
Matthew Walburn, RHCE, CCNA
Network Assistant - x. 3-4995
MIT Department of Mathematics
Jérôme Warnier | 3 Dec 20:06 2003
Picon

GNOME and Debian deployment

I haven't seen much trafic on this list yet. Maybe you are all too busy
with deployment?

Well, I wanted you to know what I've done for the last year at least in
a small business (+-60 person).

Most of the things I've done is described (mostly in French) on the
following link but I'm going to explain it shortly here too:
http://www.bxlug.be/migration-dupedi

It tells how and why and everything about the migration of a SME using
Windows (NT and 2000) and Mac stations to Debian GNU/Linux with GNOME
(1.4). And guess what? It makes sense!

So, they have Mac stations which remain unmodified for the moment
(pre-press applications needed). But everything else has changed at
least a bit.

To start: no more MS Office, OpenOffice.org is now on every machine,
under GNU/Linux and Windows. Some MS Access remain, though.

Next, their mail, file and print servers migrated to GNU/Linux, but we
don't care here, as we are talking about GNOME.

Most of the workstations are now running Debian GNU/Linux Woody, with
GNOME 1.4 and OOo 1.0, Evolution 1.2, ... Everything is running really
fine, on average low-end PC (PII 300MHz with 128MB RAM are common) but
we wanted more. More features, more compatibility, more performance, ...
And the next version (which is already in test on 4 machines) brings it
all: GNOME 2.2 and OOo 1.1, Evolution 1.4, and a now (at last!) fast
Nautilus, ...

The GNOME 2.2 backported packages are those of James Strandboge, and we
contributed a lot to it. OOo 1.1 is the Debian packages backported
already for Woody with GNOME 2.2 (feature nice Ximian icons, ...) which
we made ourselves.

All the packages we added to those already found elsewhere are on
http://apt.bxlug.be/backport-from-sid-to-woody,
http://apt.bxlug.be/gnome2.2, http://apt.bxlug.be/ooo/.

Central authentication is managed using NIS.
The homes of the users are stored on the file server and accessed
through NFS (seems to cause some trouble with OOo 1.0, though).
Printing is done through CUPS.
E-mail is accessed using IMAP.
Workstation installations/reinstallations are done in a breeze using
Replicator.

Feel free to ask if any questions.
Regards.
--

-- 
Jérôme Warnier <jwarnier <at> beeznest.net>
Pete Harvey | 27 Oct 17:42 2003
Picon
Picon

Launching applications at startup

Hi Guys,

I'm looking for a way to automatically launch an application when a user
logs in (Gnome 2.2).  I've looked at default.session which nearly does
what I want but fails for two reasons:

1) If user already has their own gnome session profile it'll be ignored.
2) PITA to add/remove entries safely from default.session when
installing package from an RPM.

Any other ideas?

Cheers,
Pete
Gregory Leblanc | 18 Sep 05:08 2003

[Fwd: Lockdown stuff]

Here are some thoughts from one of our favorite gnome panel hackers
about the lockdown stuff that will be worked on in the next GNOME
release cycle.  Lots of good ideas, but if there are things missing, now
is certainly the time to bring them up.
	Greg

From: George <jirka <at> 5z.com>
Subject: Lockdown stuff
Date: 2003-09-17 19:30:29 GMT
Here's what I have on lockdown currently, sort of just a draft quality
of course.

Different lockdown goals:

  1) Full lockdown (public access terminal)
  2) Partial lockdown (corporate desktop to ease support, panel locked,
     but user can read write files and all launch apps and change some
     prefs)
  3) Minimal lockdown of certain parameters
     (lockdown of specific config parameters while leaving
      rest relatively free.  Perhaps forcing a panel of
      company 'mandated' launchers, etc...)

Currently we have in 2.4:

  GConf can lock down certain keys.  For lockdown of specific simple settings
  this is fine.  For forcing a specific panel setup it is icky.  Some apps
  still do not check for keys being writable before writing it.  I've fixed
  gnome-panel, gnome-applets, gnome-utils, nautilus, eel and gconf-editor
  to respect key-writability in the UI (make choices not possible if we can't
  do them).

  For most applications this will suffice I believe.  We perhaps need an
  easier tool to work this though.  For the core desktop apps like panel
  and nautilus this only really fits goal #3 above.

  I'm not sure of the control center status, but I think for that what we
  have suffices as long as the UI respects key-writability (which I suppose
  it doesn't currently).

#include <rant-on-how-simple-this-would-have-been-if-we-used-pong.h>

Currently on gnome-panel/gnome-applets HEAD:

  I've done some changes in gnome-panel and gnome-applets to try to implement
  things needed for #1 and #2.  There is a "full lockdown" reminiscent of
  the commie mode.  This is for #1 and some setups in #2.  This setting gets
  propagated to applets which then disable properties.  Basically this means
  that all the UI that allows user to change stuff is not visible.  The key
  for this is currently: 
    /apps/panel/global/locked_down

  For partial lock down, I think it suffices to make it possible to lock down
  a specific panel rather then going down to individual applets.  You can
  do individual applets (especially launchers) with the key-nonwritability
  stuff anyway.  The thing is that I could just HIDE or MOVE the panel with
  the locked applets such that they would in effect be no longer available,
  so I think it kind of defeats the purpose.  On the other hand having a
  whole panel locked down means I could force say a bottom panel with menus
  and launchers set by the admin and disallow the user to change this panel,
  but the user could add a new panel to have some personal setup.  The bottom
  panel would be unmovable and always there so that support could rely on
  having this panel always there for users.  Again all applets and objects
  on this panel act as locked down so you can't change their setup either.
  In effect it's just as locked down as in full lockdown except it's only
  this panel.  The key for that is:
    /apps/panel/profiles/≤profile name>/toplevels/≤panel name>/locked_down

  Now this solves the "locked down" state for the panel.  But there are
  other things you may need in #1 and sometimes #2.  For one it is the
  inhibition of command line.  So I'm currently using the key
    /desktop/gnome/lockdown/inhibit_command_line
  (the reason for 'inhibit' rather then 'allow' is that just in case the
  schema is not installed or messed up, the user doesn't get a weird setup
  by default.  Like right now there is no schema for this:)
  In this mode all places where the user could enter some command name
  are disabled (and a bit more).  For example you can no longer edit
  launchers obviously since you could change their command.  Some settings
  and UI are disabled which are not necessairly a command line thing
  but related.  For example you can't anymore run procman from the monitor
  applet in this mode (I suppose being able to kill a process then is a
  command line kind of thing).  Perhaps we need more granularity here.
  Another thing is that the device setting in modemlights are disabled,
  though I'm not sure of this, perhaps that's too anal, it won't allow
  dragging launchers from desktop to panel though.

  In any case.  If only the inhibit_command_line key is on, it is
  of course not hard to get around it.  If you can edit/create text files
  you could create a .desktop file and drop it on the panel and then
  run it.  Workarounds there are 1) make sure the user can't do that
  by locking down something in nautilus 2) remove text editor from the
  menu 3) ignore drops of user owned .desktops in this mode.  I've considered
  the third option and I think it is good.  But in any case I'm sure if
  this is the only mode that's turned on, a resourceful user will be
  able to 'run' some binary.  Obviously this is to prevent 99% of the
  users from doing it.  I suppose if you run lots of desktop stations,
  for corporate use, most people will not even try to get around the
  restrictions.  So it's a question of how anal we wish to be, though
  I think that to be perfect it's a little bit of a losing battle.

  The last thing implemented is locking down the ability to "force quit"
  an app.  I suppose some places might want an 'always on' app that can't
  be quit.  If we allow 'force quit' from the panel (or elsewhere) the
  user could just whack it.  I don't think this needs to inhibit the
  metacity 'app is not responding to close, want to whack it' dialog
  since such an app would respond to close by not wanting to close
  and would never be 'non-responsive'.  The key for this currently
  is:
    /desktop/gnome/lockdown/inhibit_force_quit

Onlineness or Offlineness of lockdown:

  Note that all the stuff mentioned above is really not followed 'online'
  that is a key cannot become non-writable online and expect the UI
  to update self accordingly.  Same with the lock down keys noted above.
  Basically after a sysadmin does some changes they must force a restart
  of all sessions.  I think this is reasonable anyway.  It would be
  lots of random code to make this online changable and since such setups
  are usually not tested well, it would be more likely broken anyway.
  So in interest of simplicity and the fact that there is no GUI way
  to implement lockdown, there need not be online changes of such state.

Further work that needs doing:

  Panel:

    Locked out applets.  Basically the id's of the applets that the
    panel should not add or load.  I will work on this next, probably
    a key such as
      /apps/panel/global/disabled_applets

  Nautilus:

    Someone really needs to look at nautilus and lockdown.  I think this
    may be tougher then panel in this respect.  For the #1 scenario I
    think disabeling nautilus is best.  Public access terminal will likely
    want just access to some apps, a web browser and such.  Such terminals
    however usually wipe the home dir after use anyway, so this all
    depends on individual requirements.  Definately any place where
    commands can be run must be protected using the inhibit_command_line,
    and this includes running executables.  Note that this really gets
    weirder with nautilus since you might want to allow some things to
    be run and some not.  Desktop launchers are probably to be
    runnable.  Browsing to /usr/bin likely not.  Also browsing to
    /usr/share/applications and running something not in a menu is
    likely a non-no here as well.  Probably further configuration is
    needed here.  The user could be forced to only his home directory
    and to running only .desktop's and never direct executables.

  Evolution:

    Here probably the "follows writability of keys" is enough.  Though
    obviously inhibiting command line should make it impossible to
    run any executable or script received through email I suppose.

  gnome-terminal (and similar apps):

    I think it should refuse to run a shell if inhibit_command_line
    is on.  This just so that in case the user figures out some way
    to launch it even if it's not in the menus, he doesn't get
    anywhere.  Same goes for things that are really things for
    command line stuff.

  Menus:

    This should be fun.  There are several needs here
      1) Make it possible to make menus read only, basically ignore
      2) different menus per user while taking them all from system
         location (I'm not sure if this is possible, I need to look
         in the current menu spec)
      3) ability to perhaps disable a list of icons.  This would make
         it simple to just disable certain apps without doing much
         voodoo with the menus.  That is, specify a list of .desktops
         that the vfolder code would just ignore then.

  Control Center:

    Needs to follow key-writability in the UI.  I haven't looked at
    this much.  For scenario #1 you'd probably not want this in the
    menu at all.

Phew!  This took me long to write ...

George

--

-- 
George <jirka <at> 5z.com>
   A physical understanding is a completely unmathematical, imprecise, and
   inexact thing, but absolutely necessary for a physicist.
                       -- Richard P. Feynman
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Konstantin Riabitsev | 11 Sep 22:21 2003

GConf

Sep 11 15:22:43 grads-26/grads-26 gconfd (dpierce-6032): Erreur durant
la libération du verrou de fichier : Impossible de supprimer le verrou
de répertoire « /home/einstein/dpierce/.gconfd/lock » : Le répertoire
n'est pas vide.
Sep 11 15:22:43 grads-26/grads-26 gconfd (dpierce-6032): Sortie

I think this means:

"Something very fishy about the liberation of Duran-Duran: It's
impossible to have a more supreme repertoire. However, their repertoire
doesn't include "living la vida loca." Sorry about that."

Sheesh. Good thing the user didn't select "Chinese" as their session
language, or it would've made no sense at all. :)

Yes, I'm mocking, but you see the point. Syslog should only receive
messages in the default system locale, otherwise it's an inconvenience
at the least, and a security problem at the most, since the
administrator is not able to read warning messages in the log reports.

Cheers,
--

-- 
Konstantin ("Icon") Riabitsev
Duke Physics Sysadmin, RHCE

Gmane