[E-devel] Entrance not working with /bin/tcsh

2007-02-13 Thread Gregory Kriehn
Folks,

With the code cleanup of entrance several months ago, a user can no
longer login with entrance using /bin/tcsh.  This problem was fixed
about a year ago, but cropped up again and has never been fixed.  If
possible, I'd like the problem to be addressed.  Here is the background
info once again regarding the bug:

 There IS a reason for using /bin/sh and not the user's shell, and 
 that explains the mess at that part of the code. Check the following 
 commit.

 -
 revision 1.80
 date: 2005/12/10 05:55:09;  author: xcomputerman;  state: Exp;  lines:
 +1 -1
 I thought I had committed this...
 Force usage of /bin/sh to execute session to avoid problems with csh 
 users.
 -

 The exact Reason can be seen from the tcsh man page

 
 -l  The shell is a login shell.  Applicable only if -l is the only
 flag specified.
 

 So there you go, you can't do csh -l -c xxx, it won't work, and the
 latest commit will give problems to users with their default shell set
 to csh.
---BeginMessage---
Hi Greg,

I seems to have problems committing to the entrance cvs, so I have
attached a cvs diff here for you to try and commit it.

Cheers,
Phuah Yee Keat

Gregory Kriehn wrote:
 Phuah,
 
 It looks like your highlight of the problem has not been folded into the
 most recent commits of entrance yet.  Is it possible for you to bump
 this back up?
 
 I have confirmed, once again, that it is indeed tcsh/csh causing the
 problem.
 
 Thanks!
 Greg
 
 On Fri, 2006-09-15 at 10:15 +0800, Phuah Yee Keat wrote:
 The latest entrance commit makes it incompatible with tcsh.

 I am reproducing the mail I sent to the list below:

 ---
 Hi,

 Sorry that this came in late. The latest entrance patch have some problems

 -
 revision 1.86
 date: 2006/08/31 14:37:37;  author: essiene;  state: Exp;  lines: +73 -24
 - Commit Entrance shell utilization patches from Eugen Minciu... they
 work like a charm  :)
 - Update TODO
 -

 There IS a reason for using /bin/sh and not the user's shell, and that
 explains the mess at that part of the code. Check the following commit.

 -
 revision 1.80
 date: 2005/12/10 05:55:09;  author: xcomputerman;  state: Exp;  lines: +1 -1
 I thought I had committed this...
 Force usage of /bin/sh to execute session to avoid problems with csh users.
 -

 The exact Reason can be seen from the tcsh man page

 
 -l  The shell is a login shell.  Applicable only if -l is the only
 flag specified.
 

 So there you go, you can't do csh -l -c xxx, it won't work, and the
 latest commit will give problems to users with their default shell set
 to csh.

 Cheers,
 Phuah Yee Keat
 
? entrance_session.cvsdiff
Index: entrance_session.c
===
RCS file: /var/cvs/e/e17/apps/entrance/src/client/entrance_session.c,v
retrieving revision 1.89
diff -r1.89 entrance_session.c
843,844c843
} else {
  res = execl(/bin/sh, /bin/sh, -l, -c, buf, NULL);
---
}
846,853c845,847
  /* Getting here means the previous didn't work 
   * If /bin/sh isn't a login shell run /bin/sh without loading 
the profile
   * Also log a warning because this will probably not behave 
correctly */
  if (res == -1) { 
 /*TODO: should actually hit the user in the face with this 
message*/
 syslog(LOG_NOTICE, Neither '%s' or '/bin/sh' are working 
login shells for user '%s'. Your session may not function properly. 
,shell,user);
 execl(/bin/sh, /bin/sh, -c, buf, NULL);
  }
---
/* For csh, the above will fail, because csh does not like '-l -c cmd'
 * fallback to using default shell */
res = execl(/bin/sh, /bin/sh, -l, -c, buf, NULL);
855,858c849,855
  /* Damn, that didn't work either.
   * Bye! We call it quits and log an error 
   * TODO: Also hit the user in the face with this! (ouch!)*/
   syslog(LOG_CRIT, Entrance could not find a working shell to 
start the session for user: \%s\.,user);
---
/* Getting here means the previous didn't work 
   * If /bin/sh isn't a login shell run /bin/sh without loading the profile
   * Also log a warning because this will probably not behave correctly */
if (res == -1) { 
 /*TODO: should actually hit the user in the face with this message*/
 syslog(LOG_NOTICE, Neither '%s' or '/bin/sh' are working login 
 shells for user '%s'. Your session may not function properly. ,shell,user);
 execl(/bin/sh, /bin/sh, -c, buf, NULL);
859a857,861
 
/* Damn, that didn't work either.
   * Bye! We call it quits and log an error 
   * TODO: Also hit the user in the face with this! (ouch!)*/
   syslog(LOG_CRIT, Entrance could not find a working shell to start the 
 session for user

Re: [E-devel] entranced problems

2005-11-23 Thread Gregory Kriehn
Morten,

 this looks to me like the session fails to execute... have you looked
 at /var/log/Xorg.0.log (or whatever file your X11 server logs to) ?

That was one of the first things I looked at.  No help.  There are no
visible errors in the X server log.

 what session have you selected in entrance, and what does the 
 entrance_config.cfg entry for that session contain?
 
 ecore_config /etc/entrance_config.cfg get /entrance/session/n/session
 
 replace n with the number of your selected session, the top one in list is 0

I have selected enlightenment as my default session:

elisha: ~ ecore_config /etc/entrance_config.cfg
get /entrance/session/0/session

default

elisha: ~ ecore_config /etc/entrance_config.cfg
get /entrance/session/1/session

/usr/bin/enlightenment

elisha: ~

The easiest way to verify this is to note that I've changed
/etc/X11/prefdm, /etc/X11/xdm/Xsession, and /etc/sysconfig/desktop
to use entrance as the default login manager and enlightenment as the
default session.  Here are the relevant changes made to the files:

-

Get entrance setup:

Here are the steps:

1. We integrate E into the FC evironment. i.e in /etc/X11/xdm/Xsession
we try to add some lines for E. Try to locate the relevant parts and
insert.

[SNIP]

case $1 in
failsafe)
   exec -l $SHELL -c xterm -geometry 80x24-0-0
   ;;
gnome)
   exec -l $SHELL -c $SSH_AGENT $DBUS_LAUNCH gnome-session
   ;;
# The following changes have been made:
Enlightenment)
   exec -l $SHELL -c $SSH_AGENT $DBUS_LAUNCH enlightenment
   ;;
# End of changes
kde|kde1|kde2)
   exec -l $SHELL -c $SSH_AGENT $DBUS_LAUNCH $SWITCHDESKPATH/Xclients.kde
   ;;
twm)
# fall back to twm
   exec -l $SHELL -c $SSH_AGENT $DBUS_LAUNCH $SWITCHDESKPATH/Xclients.twm
   ;;
*)

[SNIP]

2. We edit  /etc/X11/prefdm to tell the system to launch Entrance...

[SNIP]

 elif [ $DISPLAYMANAGER = XDM ]; then
 preferred=xdm
 # We add this line but remember that it has to match 
/etc/sysconfig/desktop
 elif [ $DISPLAYMANAGER = E17 ]; then
 preferred=entranced
 # End of changes
 elif [ -n $DISPLAYMANAGER ]; then
 preferred=$DISPLAYMANAGER
 fi
fi

[SNIP]

# If we're in early-login mode and something is running, bail out
if grep -q early-login /proc/cmdline 2 /dev/null ; then
 if [ -n $preferred ]; then
 pidof $preferred /dev/null 21  exit 0
 fi
 pidof gdm-binary /dev/null 21  exit 0
 pidof kdm /dev/null 21  exit 0
 pidof xdm /dev/null 21  exit 0
 # Add this line
 pidof entranced /dev/null 21  exit 0
 # End of changes
fi

[SNIP]

# Fallbacks, in order
# First, fallback to entrance...
entranced $@ /dev/null 21
if [ $? -ne 127 ]; then
 exec $0 $@
 exit $?
fi
# End of changes
gdm $@ /dev/null 21
if [ $? -ne 127 ]; then
 exec $0 $@
 exit $?
fi

[SNIP]

3. Make sure your /etc/sysconfig/desktop ressembles this:

  DISPLAYMANAGER=E17

The most important change is that /etc/sysconfig/desktop should say
DISPLAYMANAGER and *not* DESKTOP because of the environment variable
in /etc/X11/prefdm (I think this may actually be a FC4 bug.)  Also, if
people would rather fallback to gnome first (or something else), you can
just move the new fallback code to the desired place with regard to order
of importance (i.e., after the gdm snippet).  


Cheers!
Greg

-

These changes were working up until around the 15 of October or so, when
new changes to the CVS tree hit.

Thanks,
Greg



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] entranced problems

2005-11-22 Thread Gregory Kriehn
Ehud,

This seems to already be accounted for in Didier's repositories.  Doing
a locate on entrance_config gives me a entrance_config.cfg file, but
no entrance_config.db file.

I seem to be experiencing the exact same problem mentioned on
edevelop.org:

http://edevelop.org/node/1479

It's a permissions problem, and the flickering behavior mentioned there
is exactly what happens with me as well.  Logging in as root still
works.

Please read the bug report, especially the last comment or two and let
me know what you think.  Here's the interesting info:

-

I have been having this
Submitted by Anonymous on Wed, 2005-10-19 16:43.
I have been having this problem too. Compiled everything from CVS that I
updated on Friday last. Did some googling of this problem and set
runlevel a (I'm using Gentoo 2005.1) in inttab to:

 /usr/local/sbin/entranced -nodaemon

This gave me meaningful output. It's failing in auth.c, here:

/* Make sure the file can be written to */
+  if((auth_file = fopen(d-user_authfile, a+)))
+ fclose(auth_file);
+  else
+  {
+ entranced_debug(entranced_auth_user_add: Unable to write auth file 
%s, 
d-user_authfile);
+ free(d-user_authfile);
+ d-user_authfile = NULL;
+ return FALSE;
+  }

I set the permissions on my home directory to 777, touched
an .Xauthority file with permissions [Sign of Satan] and this check
still failed. Tried everything in any page on these forums and just
general xauth problems. Nada. Zippo. Still get: 

AUDIT: Wed Oct 19 11:28:25 2005: 10256 X: client 2 rejected from local
host

AND entranced never gets permission to start E17 because it can't write
the cookie into the xauth file. Even tried setting entranced to setuid
root, but permission check still failed. Not sure what else to try.

Any ideas? Please email me if you have an answer. 

 Thanks!

Jon Brisbin, NPC International, jon dot brisbin at npcinternational dot
com 

-

Thanks!
Greg

On Sat, 2005-11-19 at 11:00 +0200, Ehud Shabtai wrote:
 On 11/18/05, Gregory Kriehn [EMAIL PROTECTED] wrote:
  For whatever reason, entrance is no longer allowing me to login using
  the graphical login process (I'm using Didier's repositories).  init
  level 3 works, however, using startx.  Here are the relevant messages
  from /var/log/messages regarding what is happening (under init level 5):
 
 I had the same problem. I think entranced has now discontinued its
 support for the edb config file. So if you used
 /etc/entrance_config.db as your configuration file, you now need to
 build a /etc/entrance_config.cfg file instead (use the build_config.sh
 script).
 
 Ehud.



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] entranced problems

2005-11-17 Thread Gregory Kriehn
For whatever reason, entrance is no longer allowing me to login using
the graphical login process (I'm using Didier's repositories).  init
level 3 works, however, using startx.  Here are the relevant messages
from /var/log/messages regarding what is happening (under init level 5):

Nov  7 16:08:29 elisha entrance: Debug: ipc_title
= /var/entrance_ipc_5132
Nov  7 16:08:29 elisha entrance: entrance_ipc_init: Success
Nov  7 16:08:36 elisha entrance: PAM: Success.
Nov  7 16:08:37 elisha entrance: entranced: Requesting auth for uid 500
(/home/kriehn)
Nov  7 16:08:37 elisha entrance: Executing /etc/X11/xdm/Xsession
Nov  7 16:08:37 elisha entrance: Starting session for user kriehn.
Nov  7 16:08:37 elisha entrance(pam_unix)[5205]: session opened for user
kriehn by (uid=0)
Nov  7 16:08:37 elisha entrance[5205]: Opened PAM session. kriehn : :0.
Nov  7 16:08:37 elisha entrance[5205]: entrance_ipc_shutdown: Success
Nov  7 16:08:37 elisha entrance[5205]: Replacing Entrance with simple
login program to wait for session end.
Nov  7 16:08:37 elisha kernel: agpgart: Found an AGP 3.0 compliant
device at :00:00.0.
Nov  7 16:08:37 elisha kernel: agpgart: Putting AGP V3 device at
:00:00.0 in to 8x mode
Nov  7 16:08:37 elisha kernel: agpgart: Putting AGP V3 device at
:01:00.0 into 8x mode
Nov  7 16:08:37 elisha entranced: The session has ended normally.
Nov  7 16:08:39 elisha kernel: agpgart: Found an AGP 3.0 compliant
device at :00:00.0.
Nov  7 16:08:39 elisha kernel: agpgart: Putting AGP V3 device at
:00:00.0 into 8x mode
Nov  7 16:08:39 elisha kernel: agpgart: Putting AGP V3 device at
:01:00.0 into 8x mode
Nov  7 16:08:39 elisha entrance: Debug: ipc_title
= /var/entrance_ipc_5132

So, the entrance daemon is running, a login request is received, a
session started, and then the daemon immediately shuts down and
restarts.  I tried to find some lower level debugging info, but failed
to do so.  This is not a PAM issue, as I've copied gnome's permission
file over to /etc/pam.d/entrance, which has been working for me for a
couple of months now.

Any takers on this?

Thanks!
Greg




---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Console permissions

2005-08-18 Thread Gregory Kriehn

Sebastian,

So...that would mean simply copying the

/etc/pam.d/gdm

file to

/etc/pam.d/entrance

and replacing it?

The contents of the two files are different.

I'm using Didier's repositories, which are direct, stable' builds from 
the current cvs directory...so yes...I would assume that I'm using the pam 
file from cvs, especially since the /etc/pam.d/entrance file exists.


Any clarity you could offer would be greatly appreciated!

Thanks,
Greg

On Wed, 17 Aug 2005, Sebastian Dransfeld wrote:


Date: Wed, 17 Aug 2005 04:14:04 +0200
From: Sebastian Dransfeld [EMAIL PROTECTED]
To: Gregory Kriehn [EMAIL PROTECTED]
Cc: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] Console permissions

Gregory Kriehn wrote:
There seems to be a bug when logging into enlightenment via entrance with 
regard to console permissions for sound events.


Are you using the pam file from cvs? It doesn't honour fedora stuff like 
pam_console. You need to use the pam file from gdm/kdm whatever.


And if you are using an older entrance, then it's a real bug that is fixed in 
cvs.


Sebastian




---
SF.Net email is Sponsored by the Better Software Conference  EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile  Plan-Driven Development * Managing Projects  Teams * Testing  QA
Security * Process Improvement  Measurement * http://www.sqe.com/bsce5sf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Console permissions

2005-08-16 Thread Gregory Kriehn
There seems to be a bug when logging into enlightenment via entrance with 
regard to console permissions for sound events.


In Fedora Core 4, there are some default permissions found in:
/etc/security/console.perms.d/50-default.perms.  For sound events, the 
appropriate device classes are given by:


sound=/dev/dsp* /dev/audio* /dev/midi* \
/dev/mixer* /dev/sequencer \
/dev/sound/* /dev/beep \
/dev/snd/*

and the permission definitions are provided by:

console 0600 sound 0600 root

Therefore, when someone logs into a console, the user should take control 
of the sound device classes and be able to read/write to them.  For 
example:


elijah: /dev ls -l /dev/dsp
crw--- 1 kriehn root 14, 3 Aug 15 01:55 /dev/dsp
elijah: /dev

However, when logging into X via E17, the permissions for sound are not 
transferred, and root maintains control of all the sound classes, thereby 
disabling sound.  This can be avoided if a user first logs into a 
console terminal (and stays logged in) before logging into X.  The 
permissions are then transferred correctly.


This sounds like it should be an easy fix, especially since other 
permissions seem to be transferred correctly.


One other note -- I am running gnome-panel with the volume control 
applet in E17 as well.  Perhaps there is some gnome-e17 infighting going 
on?


Thanks!
Greg


---
SF.Net email is Sponsored by the Better Software Conference  EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile  Plan-Driven Development * Managing Projects  Teams * Testing  QA
Security * Process Improvement  Measurement * http://www.sqe.com/bsce5sf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel