-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wemux users only returns root #16
Comments
Thought I'd update. Despite my relatively novice scripting ability I managed to make an addition to the script so that it works on my system. For those who are interested the addition I made to the status_users() function is between the ##### lines in the code below: status_users() {
if [ "$allow_user_list" == "true" ]; then
while IFS= read line; do
read tty mode <<<$(echo $line)
############################
# Check if tty is a symlink
if [ -L $tty ]; then
tty=`readlink -f $tty`
fi
############################
# Get user associated with tty
name=`stat -f%Su $tty 2>/dev/null` || name=`stat -c%U $tty 2>/dev/null`
# If user is attached in read-only mode, set mode to [m]
[[ $mode == "(ro)" ]] && mode="[m]" || mode=""
# If user/mode is already is userlist, do not add them again.
if ! [[ "$users" =~ "$name$mode," ]]; then
users="$users$name$mode, "
fi
done < <(wemux list-clients | cut -f1,6 -d ' ' | sed s/://)
# Strip last two characters ', '
echo "${users%??}"
else
echo "User list disabled."
return 126
fi
} This does require that you have readlink on your system, and I've read that Solaris 10 doesn't ship with this by default (big surprise), but I have installed the CSWcoreutils package which includes it. After fixing this I found a problem with the kick_user() function on my system. The line of script causing the issue for me is: # Get sshd process with users name and get its PID.
user_pid=`ps aux | grep "$kicked_user.*sshd" | grep -v grep | tr -s ' ' | cut -d ' ' -f 2` Due to the way Solaris implements ps, the flags 'aux' needed to be different. I changed to ps -ef. Solaris prints the output columns in a strange order, so the grep functions needed changing as well. In conclusion, if you run Solaris 10 change the line above to: # Get sshd process with users name and get its PID.
user_pid=`ps -ef | grep "$kicked_user.*sshd" | grep -v grep | awk '{print $2}'` I'm sorry for not making these fixes in a more generic way, so that they can be added to the main code and work for every system... as I said before, I am a novice scripter and not a programmer at all. I hope this post helps someone else stuck on Solaris. I'd like to say that Wemux is VERY handy, and thank you for making it! I am a network engineer and have been using Wemux to remotely train new staff on my team. It's much easier for them to watch and help me configure routers directly and on their own screens instead of looking over my shoulder, plus I can work from home this way ;) -matt |
Thank you very much, I'm glad wemux has been useful for you! I don't have a Solaris machine at the moment to test and integrate this into wemux proper but I'll see what I can do. Thanks for putting in the work and finding appropriate Solaris flags! |
The system I am stuck working on is Solaris 10.
As the title states, when listing users attached to the server the entire list is always:
homerville:{calculoid} $ wemux users Users attached to 'wemux': 1. root
This also has the effect that I can't kick anyone. I sniffed around in the script and see that the result is coming from the line:
It only returns root on my system. I assume this is a solaris thing, because it always is if something is weird.
When I check tty on the command line and then check the owner of the pts returned it is always root.
homerville:{calculoid} $ ll /dev/pts/20 lrwxrwxrwx 1 root root 29 Feb 25 2008 /dev/pts/20 -> ../../devices/pseudo/pts@0:20
Checking a little further shows that /dev/pts/ is filled with symbolic links owned by root that point to files owned by the user they were created for:
Announcements that a particular user is joining or leaving the server work correctly.
The text was updated successfully, but these errors were encountered: