Auteur Sujet: Problems with LXDE  (Lu 70666 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne patrick013

  • Membre Senior
  • ****
  • Messages: 252
Re : Re : Re : Re : Re : Problems with LXDE
« Réponse #45 le: 07 juin 2013 à 21:21:10 »
Without knowing more about how you did the installation and what steps you took to create multiple guest users, I could only guess as to what caused your original problem with being able to log out. You say that a program is "running as root" when you logout. If by that you mean that there is an application that you manually started as user root, then I fail to see why you would want to leave it running during a logout, reboot or shutdown. If you mean that there are system services that were started by user root, that is normal and is part of the sysvinit bootup process.
guest:x:1000:guest
wheel:x:1001:
polkituser:x:1002:guest

With guest as a member of group 1000 and also a member of group 1002
I am able to use Melodie's .pkla file and shutdown when there are root
programs open.    Which is what I wanted to do anyway.

The install was a remaster and reinstall of an original Scorpio from Taco.
The iso was like 1 GB, too big for a remaster IMO.    But it will shutdown
when I close root programs, now it shutdowns when I don't.

Try it, copy the 55-myconf2.pkla file to your install and setup the group
for polkituser, add yourself as user there, and it will shutdown when root
programs are open and running.

Shutdown LXDE when root programs are open

Have a good one,

Patrick

djohnston

  • Invité
Re : Problems with LXDE
« Réponse #46 le: 08 juin 2013 à 05:58:42 »
I do intend to take advantage of mimas's obsession package. Anything that makes things simpler is best, in my opinion. And consolekit is anything but simple.
Done. Works like a charm!

Thanks, mimas!!




Hors ligne Taco.22

  • Membre Senior
  • ****
  • Messages: 391
    • Scorpio_Openbox
Re : Problems with LXDE
« Réponse #47 le: 08 juin 2013 à 07:07:07 »
Yeah, mine used to look like that!  Don't know what went wrong but I now have those icons installed into a rather large number of places and they still won't show up.  Did you use the Debian compiled or the source with installer?
What can go wrong !!!

djohnston

  • Invité
Re : Re : Problems with LXDE
« Réponse #48 le: 08 juin 2013 à 10:42:04 »
Did you use the Debian compiled or the source with installer?

I had to use the source to change "Openbox" to "JWM" in the displayed message. Then just do: $make #make install. The icons you see in the screenshot aren't the ones mima supplied. However, I got them to show up by copying them from /usr/local/share/obsession/images to /usr/share/pixmaps. After installing, I discovered the Logout function called by obsession isn't working in JWM. Kinda weird.

Hors ligne Taco.22

  • Membre Senior
  • ****
  • Messages: 391
    • Scorpio_Openbox
Re : Problems with LXDE
« Réponse #49 le: 08 juin 2013 à 12:26:21 »
Ahh, it just all got too hard!!  I'm just going to stick to the logout commands in Openbox root menu as written in menu.xml.  Simple, precise and trouble-free - no need for a GUI.
What can go wrong !!!

Hors ligne melodie

  • Administrateur
  • Membre Héroïque
  • *****
  • Messages: 1777
    • Citrotux
Re : Re : Problems with LXDE
« Réponse #50 le: 08 juin 2013 à 17:17:52 »
Ahh, it just all got too hard!!  I'm just going to stick to the logout commands in Openbox root menu as written in menu.xml.  Simple, precise and trouble-free - no need for a GUI.

You both are talking about two different types of desktops. I don't quite see what is so hard? Is it about the icons? I was almost sure that having them directly under /usr/share/pixmaps would solve it, as djohnston confirms. Up to now any icon trouble was solved without problem by doing so.

For me it's not just the gui, it's nice looking and gives even more a feeling of having a real Desktop environment and it has also made my main menu shorter, I like it this way. :)




Good leaders being scarce, following yourself is allowed.

Hors ligne Taco.22

  • Membre Senior
  • ****
  • Messages: 391
    • Scorpio_Openbox
Re : Problems with LXDE
« Réponse #51 le: 09 juin 2013 à 02:35:46 »
I used the Debian configured version, and I have put those icons EVERYWHERE, and they still don't show up on the obsession menu!!  I've tried the installer a couple of times but I'm getting config errors.  However this is all for a Spacefm based "desktop" which I'm having second thoughts about.  There is a reason why I developed Scorpio as it is - it is, to my mind, the "ideal" Openbox setup; in fact the "ideal" OS.
What can go wrong !!!

djohnston

  • Invité
Re : Re : Problems with LXDE
« Réponse #52 le: 09 juin 2013 à 04:46:15 »
I'm just going to stick to the logout commands in Openbox root menu as written in menu.xml.  Simple, precise and trouble-free - no need for a GUI.

I'm considering doing the same thing. Only it will be in ~/.jwmrc (which is written in XML). I previously had the menu set up that way.


Hors ligne mimas

  • Général du Roi
  • Membre Complet
  • ***
  • Messages: 114
  • Jamais content
    • G+
Re : Re : Problems with LXDE
« Réponse #53 le: 09 juin 2013 à 12:27:55 »
@djohnston,
Thanks for the banner. :D

> After installing, I discovered the Logout function called by obsession isn't working in JWM. Kinda weird.

Do you use obsession-exit?
If some actions aren't display in obsession-logout, maybe you could try 'obsession-exit -c' to see what power functions are detected (it shares the same code with obsession-logout).

Here I've got :
$ obsession-exit -c
Capabilities:
  Shutdown
  Reboot
  Suspend
  Hibernate
  User switch

edit : quote fixed
« Modifié: 09 juin 2013 à 14:33:04 par mimas »
When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression, no matter how holy the motives.

Hors ligne Taco.22

  • Membre Senior
  • ****
  • Messages: 391
    • Scorpio_Openbox
Re : Problems with LXDE
« Réponse #54 le: 09 juin 2013 à 14:18:07 »
Hi mimas,

I don't have any problems with obsession working - I use the command "obsession-logout" and the resulting pop-up dialogue box is fully functional.  My issue is that the icons aren't present in that box.  I think they were initially but somewhere along the line they disappeared.  As I've said before, I can't get them to appear, regardless of where I put icons - I even installed the gnome-icon-theme just in case.  Now, this isn't straight Debian Openbox - I have Spacefm controlling the "desktop" ala LXDE but without the LXDE metapackage, so who knows what may have happened under the bonnet. 
What can go wrong !!!

Hors ligne mimas

  • Général du Roi
  • Membre Complet
  • ***
  • Messages: 114
  • Jamais content
    • G+
Re : Problems with LXDE
« Réponse #55 le: 09 juin 2013 à 14:29:56 »
Yes, I was lost in the quotes.
When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression, no matter how holy the motives.

Hors ligne melodie

  • Administrateur
  • Membre Héroïque
  • *****
  • Messages: 1777
    • Citrotux
Re : Re : Problems with LXDE
« Réponse #56 le: 09 juin 2013 à 15:42:27 »
so who knows what may have happened under the bonnet.

Hi Taco,

I suppose you checked the rights and permissions of your icons where ever you put them? Where is that version of your's now, is it possible to download it to try it?

Good leaders being scarce, following yourself is allowed.

djohnston

  • Invité
Re : Re : Re : Re : Problems with LXDE
« Réponse #57 le: 11 juin 2013 à 09:20:52 »
Can you post the /etc/pam.d/lighdm file ?

I replaced LightDM with Slim, so I'll have to take the files from the standard Debian LXDE install.

/etc/pam.d/lightdm

#%PAM-1.0
auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
#auth    sufficient      pam_thinkfinger.so
@include common-auth
auth    optional        pam_gnome_keyring.so
@include common-account
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without out this it is possible
# that a module could execute code in the wrong domain.
# When the module is present, "required" would be sufficient (When SELinux
# is disabled, this returns success.)
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required        pam_limits.so
session required        pam_loginuid.so
@include common-session
# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
# When the module is present, "required" would be sufficient (When SELinux
# is disabled, this returns success.)
session optional        pam_gnome_keyring.so auto_start
@include common-password

Since common-auth, common-account, common-session and common-password are called, I'll post the contents of those.

/etc/pam.d/common-auth

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config

/etc/pam.d/common-account

#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system.  The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.
#

# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

/etc/pam.d/common-session

#
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
# end of pam-auth-update config

/etc/pam.d/common-password

#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords.  The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords.  Without this option,
# the default is Unix crypt.  Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
password optional pam_gnome_keyring.so
# end of pam-auth-update config

djohnston

  • Invité
Re : Re : Re : Problems with LXDE
« Réponse #58 le: 11 juin 2013 à 09:27:49 »
Do you use obsession-exit?
If some actions aren't display in obsession-logout, maybe you could try 'obsession-exit -c' to see what power functions are detected (it shares the same code with obsession-logout).
I don't remember. I tried one of the two. I'll try again, using both. The actions are all displayed as shown in the screenshot. Although Shutdown, Reboot and Cancel worked fine, Logout didn't. (From the window's title, I think it's obsession-logout.)
« Modifié: 11 juin 2013 à 09:30:08 par djohnston »

Hors ligne mimas

  • Général du Roi
  • Membre Complet
  • ***
  • Messages: 114
  • Jamais content
    • G+
Re : Problems with LXDE
« Réponse #59 le: 11 juin 2013 à 09:56:03 »
Obsession-exit is a CLI version of obsession-logout but It was broken until a few days ago.

I released a new version of obsession : http://code.google.com/p/mimarchlinux/downloads/list (nothing has been done to obsession-logout).

When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression, no matter how holy the motives.