Konsole item in computing menu,... help please...

[JaseP]

Thank you...

And XTerm it is... I hadn't realized it had a transparency setting,.. never bothered to use it...

[JaseP]

Trying to get my head around the user management stuff in the terminal.

The object is to put together what I need to make this launch without being root by default... With least amount of additions or changes to the system,...

The su command works fine to get me to into my admin account (net install, but I don't know if that makes a I checked /etc/passswd just to be sure... ).

On the MDs, using su for the same user gets me to the sambahelper user... I checked /etc/passswd just to be sure... and yes,... it looks as though there are no real user accounts set up on the MDs, which makes sense ... Root level commands aren't honored when logged in as sambahelper,... which I expected.

That leads me to questions:
1) The core creates users with the names; pluto_[user names first entered on setup],... Are these "true" Linux user accounts in the traditional sense (or close to it), or some sort of services process user, like for MythTV, etc?

2) What would be the preferred method for this thing working on MDs?;
     a) Do not create any users,... default to sambahelper for ordinary users, but root for admin after supplying password (Set password as system Admins?)...
     b) Set up user "secondary" accounts with names derived from LinuxMCE, putting only admins on Sudoers list ("home" being their account dir on the core),...
     c) Set up Admins with "secondary" accounts only from LinuxMCE, otherwise as b, above...
     d) No user additions,...but create 2 options, sambahelper with no root authority, ... or root after supplying system admin's password,...

3) On Core,... same as above? or only just the admin...?

I'm inclined to think that the easiest thing would be #2(c) from above, universally, on MDs and the Core (I'm assuming a hybrid core here). But not use the LinuxMCE user accounts themselves, just a parallel set of accounts. Actually, 2(d) would be easiest, at least as far as MDs are concerned. But I'm inclined to think 2(c) would be more useful from the standpoint of using this as an admin tool.

Please let me know what you think.

[l3mce]

Glad to see progress!

Now the second thing I want to get across.

Upload soon and upload often. This way we can collaborate. We can, as a community, help each other. You can choose to keep, or ignore any code changes/recommendations... but this way it is easier for us to communicate.

svn.linuxmce.org

Create a new ticket, and attach what you are working on.

[JaseP]

Thanks,...

What I've decided is that the setup script needs to create a single user on each MD (named for the Moon[n] of that MD,... Like; Moon[n]_xtermuser), and give that user rights on the sudoers list on each MD so as not to interfere with any accounts currently used by the system.

I might have some prelim test script work done by the end of this weekend. Just a "hard-coded" launcher script, maybe a "hard-coded" user setup script as well... Full scripts will have to include sql queries to the database to get the necessary system information to do an automated setup. So, I have to learn that.

I don't know what to do about the tty terminals,... I think, though, that it should be a separate, optional piece to secure them... It doesn't make sense to limit user authority on a windowed xterm, and leave the the ability to get a tty as root (by default) hanging in the wind with a simple Alt-Ctrl-F[n]. It should be theoretically possible to limit local access to tty's while allowing access through ssh from the server. From what I've read, ssh-ing into a machine that's had its local tty access restricted is not affected, since authentication happens before hand, and that mechanism bypasses the normal restrictions imposed in the /etc/securetty file... but that'll be something to experiment with. If it's a separate piece to secure the tty's, it gives the admin the decision on how much to restrict the system, based on their own requirements. It would be a simple process to "undo" the tty access restriction by replacing the /etc/securetty file with the original, should someone need to reverse it. Future refinements could allow the admin to decide WHICH MDs to restrict in this way...

Otherwise, it should be simple to cause xterm to launch as a particular user. All that's left is to create a script that sets up the users on each MD (including a hybrid Core's on-screen Orbiter), sets the limited user environment, xterm configuration, sudo permissions for them, create a device profile for the "app" (script really) that launches xterm -ls, and make some sort of change to the main menu to assign/reserve it a hotkey. ... Oh, and eventually, to create a mechanism for turning this on (& configuring?!) it in the Web Admin,... Turns out getting xterm to launch in a more secure way is the easy part,... Devil's in the details...

There are two paths for user configuration that I can take,... the easier one being to require the user to set the password for the Moon[n]_xtermuser for each MD on first login with xterm... The second is to pre-define it,... but that would (eventually) require a Web Admin config screen... I think I'll take the easy road for now. If pre-configuration is desirable, that could be a ver. 2.0 thing.

One question remains,... I have a net installed 1004 system...

By default, if I drop to a tty on my Core, I'm presented with a login prompt that allows me to logins as the original user I created with the Kubuntu install. Does the DVD install create such a user,... or does it default to a password-less root like the MDs have??

Oops,... I realized I have a second question,... It came up while I was researching xterm use with ssh, and might (though unlikely) impact some aspect of how this would work...

Is ssh forwarding allowed on the LinuxMCE system by default?

[Marie.O]

Why do you want to create a new user on each MD?

We already create users named pluto_<Name-of-user>. At the moment we disable terminal login (bei specifying /bin/false as the shell) for these users, as the default password is the <Name-of-user>, but instead of creating new users, I would see if you can re-use these users.

[JaseP]

I didn't see them on the list of user accounts when I checked the /etc/passwd file on the MD. I did notice them when I did the same on the Core. But, I'll check again (tonight, maybe)... Maybe I missed/overlooked them...

If they are only accessible by ssh-ing to the Core,... I'd have to use ssh forwarding to go from the MD, to the Core and back to the MD, adding a layer of complication. Plus,... when using xterm -ls, I don't know if the minimal user environment that I would need to define would interfere with anything set in those user accounts (which, given my luck, it would).

[Marie.O]

We are using NIS. Each user that is available on the core is available throughout the MDs.

[JaseP]

Alright, I didn't know that. Thanks. I'll have to take a look at that and how it affects launching xterm with with or without login support (e.g. there are certain xterm options that are not compatible with one another, like; xterm -ls and xterm -e, so I need to look at and understand NIS, and how it works, better)...

[tschak909]

This is why it is absolutely important to study the system. 9 times out of 10, pluto already thought of it.

NIS replicates configuration files (passwd, group, etc.)so that this data is consistent between the systems, even when changes are done.

Also, when logging into a moon, it is important for now that this is done as root, as there is an ssh key which allows this to happen automatically.

-Thom

[JaseP]

Hmmm,...

I'm thinking of a solution based on remote forwarding from the Core to the MD, and ssh-ing back to the MD (or even another MD),... But, I haven't thought it through enough to explain it correctly or figure out if it will even work... And I don't think it will resolve the issue of trying not to run a graphical terminal as root without password.

I'll keep working on it...

[JaseP]

Exploring options & Follow-up question:

I've determined that NIS and local user logins can coexist on a system,... Especially, on a PXE boot the biggest issue is how to map the local user "/home" account properly with NFS. Not simple, but certainly less convoluted than what I was considering in my previous post...

Is everyone so attached to NIS login for what would be, essentially, a bolt-on addition/convenience that you would reject a "dummy" local user account, considering that might be the least amount of change to the system and more easily removable?!

I'm not all about the easy way, over the right way, but this looks like an area where to do it, the easy way gets it done, while the right way ends up standing in line (in que, for the Brits,... ) waiting to cash a check...

[Marie.O]

Use NIS.

Don't bolt on, do it right. Takes longer, but you do learn stuff.

[JaseP]

When you say that it is important that all logins are as root,... does this have to do with key file ownership?

[tschak909]

This has to do with the fact that currently the public key for connecting to the other moons is in /root/.ssh …

Lots of things need to be privilege deescalated from root, this is an artifact of this.

-Thom

[JaseP]

So, there's no way under NIS to allow unprivileged logins from the moons under the current setup,... hmmm,..

Would switching around the NIS key file ownership/location situation break other things, under the current setup?