You are not logged in.
We now have an alternate interface for the website for those who dislike the CLI interface... go to http://cdm.ghost1227.com/X11 or run startx from the CLI interface to view it.
Offline
Hmm... I appear to be having server issues... Maybe you should use the -git version?
i dont know why but i feel more comfortable with versioned releases.. anyway, link is up again, yet the problem persists....did you suggest the issue is fixed in git only?
Offline
No, it should have worked with the stable as well... in fact, I'm using it without any problems right now... Can you post your cdmrc?
and i had to uninstall it cause i couldnt even start gdm with it installed (through inittab)
cdmrc
############################
### GLOBAL CONFIGURATION ###
############################
# Set CDM theme and dialog options
theme=cdm
countfrom=0
# List all WM binary names
wmbinlist=(gnome-session openbox-session)
# List all WM display names
wmdisplist=(gnome Openbox)
# Allow console login?
allowconsole=yes
# Allow shutdown?
allowshutdown=yes
shutdowncommand='sudo shutdown -h now'
rebootcommand='sudo shutdown -r now'
# Allow suspend?
# Note that this option requires pm-utils
# to be installed and properly configured.
allowsuspend=yes
suspendcommand='sudo pm-suspend'
# Set configuration for specific users?
userconfig=(courtney)
##########################
### USER CONFIGURATION ###
##########################
courtney() {
# Set CDM theme
theme=lime
# List user allowed WM binary names
wmbinlist=(openbox-session)
# List user allowed WM display names
wmdisplist=(Openbox)
# Allow console login?
allowconsole=yes
# Allow shutdown?
allowshutdown=no
# Set specific display for user
# (Not honored unless locktty=yes)
# display=1
}
############################
### SYSTEM CONFIGURATION ###
############################
# Set default display
display=0
# Where should first X tty be spawned?
xtty=7
# Restrict tty? (By default, cdm increments X tty, this setting
# allows administrators to lock users into one specific tty by
# setting the display=N option on a per-user basis.)
locktty=no
# Enable login shell (fixes issues with some keymaps, uses bash)
loginshell=no
# Use ~/.xinitrc when it exists, or /etc/X11/xinit/xinitrc when
# it doesn't. If no, then we instead call the chosen window
# manager directly.
usexinit=no
# Additional arguments to pass to X server; it will be called as:
# exec /usr/bin/X :$display $serverargs vt$((xtty+display))
serverargs="-nolisten tcp -dpi 96"
Offline
OK... I lied... I wasn't using it without problems. Turns out I have the same problem as eldragon now. And I do know what's causing it, I just have to figure out how to fix it
If you haven't upgraded yet, please don't until I figure out how to work around this problem
Offline
Sorry, I think it was my fault. (One of several patches I sent Ghost.) I sent him what should be a fix. If you have upgraded and are having troubles, you could try setting usexinit=yes in /etc/cdmrc. I think the problems only affect those who use usexinit=no.
Offline
Ok. A new update is posted to both stable and git that should take care of the issue for now. Unfortunately, we did loose one feature in the process but I'd rather loose that and have it stable than keep it and have it unusable. I will continue working on reimplementing that particular feature. Thanks all for the input!
Offline
Hi, I've been trying the last days to get cdm working, but never get past it; after selecting an option in cdm it redirects me to the login prompt instead of loading the wm. Here is what I did (on ubuntu 9.10 i386):
- dowload git version and sudo ./install
- edit /etc/cdmrc (attached)
- edit grub (added 'text' to line 9: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash") and update-grub, so it boots to console with login prompt
- restart
My cdmrc (options for wm's taken from the commands in the .desktop files in /usr/share/xsessions):
############################
### GLOBAL CONFIGURATION ###
############################
# Set CDM theme and dialog options
theme=cdm
countfrom=1
# List all WM binary names
wmbinlist=(/opt/e17/bin/enlightenment_start.sh /opt/e17/bin/enlightenment_start gnome-session openbox-session)
# List all WM display names
wmdisplist=(Ecomorph Enlightenment Gnome Openbox)
# Allow console login?
allowconsole=yes
# Allow shutdown?
allowshutdown=yes
shutdowncommand='sudo shutdown -h now'
rebootcommand='sudo shutdown -r now'
# Allow suspend?
# Note that this option requires pm-utils
# to be installed and properly configured.
allowsuspend=no
suspendcommand='sudo pm-suspend'
############################
### SYSTEM CONFIGURATION ###
############################
# Set default display
display=0
# Where should first X tty be spawned
xtty=7
# Restrict tty? (By default, cdm increments X tty, this setting
# allows administrators to lock users into one specific tty by
# setting the display=N option on a per-user basis.)
locktty=no
# Enable login shell (fixes issues with some keymaps, uses bash)
loginshell=no
# Additional arguments to pass to X server
serverargs="-nolisten tcp -dpi 96"
Offline
By the way, http://tech.ghost1227.com/repo/ still does not contain cdm-0.4.1.tar.gz (at least I can't find it).
Offline
Is there any way to test if a terminal was started through ssh? When X forwarding turned on, the connection gets considered as both a login shell and DISPLAY is set, so cdm starts
Offline
Offline
was the feature of only starting cdm at tty1 what broke 0.4? cause now all ttys start cdm...
Offline
@eldragon: no, that wasn't it. It was a combination of other things. I'm sorry, it was my fault. I think we'll have it ironed out soon.
@thundara: what's the behavior you're looking for? you want cdm to be suppressed when the terminal is an SSH terminal? That should be doable. We could just add a && [[ -z $SSH_TTY ]] to the first line of the profile.d script. Or are you asking for something more sophisticated? I've never played around with X forwarding, so I don't know what behavior makes sense from cdm in that case.
Offline
@thundara: what's the behavior you're looking for? you want cdm to be suppressed when the terminal is an SSH terminal? That should be doable. We could just add a && [[ -z $SSH_TTY ]] to the first line of the profile.d script. Or are you asking for something more sophisticated? I've never played around with X forwarding, so I don't know what behavior makes sense from cdm in that case.
Looks like testing SSH_TTY should do it, or at least, it'd work on my machine.
I'm having an issue with multiple users now though. Logging in the first time with a DE goes fine, but subsequent users are unable to log in to anything but console.
Also, looking through the source, I'm curious about this line:
serverargs=":${display} ${serverargs} vt$((xtty+display))"
Why is serverargs setting itself to be one of its own arguments? O.o
Offline
Maybe that's bad coding style. We fetch serverargs from the /etc/cdmrc file. At that point in the code, we're constructing a set of arguments to pass to startx. The arguments after the -- have to look something like:
:0 ${serverargs_from_cdmrc} vt7
We were just re-using serverargs as a temporary variable to hold all of that until a few lines later, where we actually called startx. Since the variable isn't exported, nothing else will see it anyway.
About multiple users: do you perhaps have locktty=yes? In that case, your different users will need to have different display=<number> settings. One of them can be the default display=0, but the others will have to be set via the "courtney" method in the example cdmrc.
If that doesn't cover your case, please tell us more about what's happening. Probably you should post your cdmrc.
Offline
Setting it up with locktty=yes and users having their own display settings worked. Not sure why it wasn't working from the default, non-locked settings, especially since running the section that generated the display value seemed to give the correct values. =/
Thanks though!
Offline
If you look at the fixed pkgbuild it no longer points to tech.ghost1227.com... the CDM repo has been moved to where it belongs at cdm.ghost1227.com/repo
Thanks - I must've gotten somehow an "intermediate" PKGBUILD (it was very soon after you uploaded 0.4.1 to AUR), and that one was pointing to the old place, and I just kept checking that instead of AUR
Offline
@thundara: OK, it sounds like you've identified a bug with the auto-increment code. The workaround is to use per-user display=<number> settings (and either use locktty=yes, or just only open one X session per user). But we should also try to get autoincrement working across different users. I realized what might be causing the problem: the xdpyinfo call is probably only reporting back about X sessions owned by the current user, so it's not detecting when a display is already taken by a different user. I'm not sure whether we can get this mechanism to work for different users; we might have to find a different way to tell which displays are currently in use.
Offline
ive modified the source a bit, so that per user config is set in ~/.cdmrc instead of having a special function in /etc/cdmrc. this is more consistent with how users setup their login (no root access required).
# Source cdm configuration
if [[ -f /etc/cdmrc ]]; then
source /etc/cdmrc
if [[ -f $HOME/.cdmrc ]]; then
source $HOME/.cdmrc
fi
countfrom=${countfrom:-0}
else
echo -e "${error} ERROR: A valid cdm configuration was not found!${reset}"
echo -e "${info} Logging out.${reset}"
sleep 3
exit 1
fi
i also removed the whole courtney and per user configuration testing in /etc/cdmrc /usr/bin/cdm respectively. i dont know how to make a patchfile.. :S
is this useful? or is there any special reason why this was implemented that way?
EDIT: there is a small issue, only my user works with cdm, other users are sent back to the login prompt (no menu is being shown). tried to figure out why this would happen, but couldnt find anything wrong.
Last edited by eldragon (2010-01-06 14:39:06)
Offline
I think it should be the site admin who decides which users are assigned to which terminals, how many X displays they can be allocated, and so on. So I think it's better the way it is. But clearly there are different opinions about this: I think this came up earlier in this thread, as well.
Offline
It was specifically designed such that only the root user could decide access levels. Good initiative though!
i gave it some thought after posting, from a security perspective, then i realized the entire script is being run as the user. nothing can stop him from doing what he wants as it is right now...seems much like security through obscurity.
maybe sourceing the entire ~/.cdmrc is not a good idea without some sanity checks, but seems much more sensible than having the admin fiddle with user's options (like theme, desktop environment, etcetera).
one last thing, in the latest version, there is no tty1 check so cdm runs whenever you login no matter which tty it was. is this on purpose?
Offline
yes. dropping the tty1 check was intentional (prevents unauthorized users from gaining terminal access). the user might run cdm, but they don't have access to change the binary, the rc file or the profile, and they can't force kill the application... it's fairly secure from your average user. I might add an option to allow users to set their own themes though...
Offline
If user doesn't have write-access to /etc/profile.d or /etc/cdmrc then on login he's not going to get the chance to run any of his dotfiles before cdm takes over. So the admin's policies for what terminals/displays this user's session gets assigned to won't be overridable by the user.
I think Ghost did remove the tty1 check on purpose.
Offline