Hi,
I was wondering if there was a “mandatory profile” under Opensuse as in Windows.
A mandatory profile is a profile that never saves its state at the end of the session and always returns to its original state chosen by the administrator.
Is it possible to imitate this operation under Opensuse?
Mandatory System or, Mandatory User?
[HR][/HR]Yes, there are methods in the UNIX® world and, therefore, also in the Linux world, which the system administrators can use to ensure that, a pre-defined behaviour always occurs at system boot time and/or when the users login to the system.
I thought about mandatory user. But I searched and found nothing about this.
How do you make this ?
Hi and welcome to the Forum 
I think you mean ‘kiosk’ mode for multiple ‘public’ users on one system? Else can always use pxe booting.
Thanks for your answer.
I make some researches on kiosk mode. It’s most like a guest session I want.
Because Kiosk is only for one application. I want a profile that can all what a user can make but the changes are not saved at the end.
Have you an other solution please? Is it possible in OpenSUSE ?
As far as I know, guest users on Unix/Linux are just created for a particular visiting person and after (s)he is gone, the user is removed. To be created fresh for the next person. Often the name guest (or a local language equivalent) is used for that account to mak life easier for the system manager.
Please read the above with the knowledge that I can completely misunderstand your posts because I have no knowledge whatsoever about MS Windows systems.
It’s exaclty what you said for a specific user and we can modify some settings on the default account only with an adminstrator account. He keeps the settings given by the administrator but not if the specific user change them.
So is it possible ?
P.S there is not a guest account on OpenSUSE. Is it?
What do you mean with “default account”? As far as I know there is none.
No there is not a “guest account” pre-configured. As I tried to explain above, a guest user/account is only one when you, as administrator think it is one and act accordingly (by removing it after usage). But it is a user as all users.
The installation suggests (strongly) to create at least one “normal” user/account (beside the root user/account) during installation. But you are not obliged to do so (and you can remove it when you want) and you can create as many others when you want.
Only you know how many human users you want to accomodate and even one human user can have more accounts (I allways strongly advice that when a person is not only doing his personal things like banking, mailing,…, but e.g. also is secretary of a sports club, best way to keep things separated for the different roles is to create a user/account for that).
Maybe you should try to forget about what you think a user/account is on a Windows system (do they exist?). The most important formula here is “Linux is not Windows and Windows is not Linux”.
BTW, in most cases when I say “you” above, I mean you the person acting in the role of system manager/administrator by using the root account (being Superuser is another wording).
And to give you somehing to look at. Look into /etc/passwd to see all the users you have on the system. Maybe even more then 20 before you start creating guest accounts.
Thanks for your answers.
Do you know if there is a way to create a user before the login ?
Before the login of whome? A user can only login if it is created.
One manages user with YaST > Security and users > Users and Groups.
Maybe some morte explanation:
You can login in the GUI as the user you created during installation. From there you start YaST. YaST will ask you for the root user’s password and then run as root do do the administrative tasks you ask from it. You carete then e.g. a new user. After that you can stop YaST, the normal user can log out from the GUI. After that the already existing user and the new user can both log in from the GUI login screen. (it is even possible to the other user(s) to start their own session while a user is already using the system, but that requires some coordination about who will sit on the chair before the system ;)).
And please try to read something about what a multi-user, multy-session system is and what it means. The different users are e.g. completely separated from each other. When one user decides he likes a dark theme in his KDE, that has no influence on the theme another user uses on KDE (or even on another Desktop Environment like Gnome). Each user has her/his own data and personal configurations. And those “normal” users can never change the systems configuration.
Hi
There used to be a guest-session in Ub*, was dropped as most users didn’t see a need…
Anyway, if you create a user called ‘guest’ and set to not use a password, maybe even set a temporary directory for this user in say RAM or /tmp and on logout clean this up (some script foo required here) and/or recreate the home directory and will be back to defaults. I guess you could also look at using apparmor to restrict applications etc for the ‘guest’ user as well.
As pointed out, it’s something that you as the system administrator can configure as required, but nothing setup out of the box so to speak.
To setup a guest user, the following seems to be needed:
It may just simply happen – the “dm-tool” seems to indicate that, a “switch-to-guest” command is built in …
Based on my SysAdmin training,
The **Mandatory Profile **is implemented in the context of supporting Roaming Profiles.
And, Roaming Profiles typically exist only when you implement some kind of network authentication.
A Roaming Profile is implemented when you want a User to sit down at any workstation in the company network and when logged in, the Workstation will by default instantly display a GUI with all of the User’s preferences and configurations… ie a specified Desktop and wallpaper, and network shares enabled using his network login as authentication and authorization.
A Mandatory Profile is configured if you want to over-ride or restrict the changes that can be made to the Roaming Profile.
So, for instance if you want to deny a group of Users in your network from being able to make changes to their applications or change the appearance.
Otherwise,
I don’t know if there is a purpose to these concepts in a network where machines don’t login to network authentication (like LDAP).
Linux fundamentally isn’t based on User security policies(beyond root or not root), so unless you install something like LDAP I don’t know that basic Linux has the foundation pieces to apply User profiles in a centralized manner… Although AppArmor does provide some pieces but IMO more for application rights on a local machine more than as a full blown User based authentication system.
As for what you describe (simply not saving changes to the User’s environment), I’d imagine that a fairly standard Roaming Profile or something similar could be implemented, saving a copy of all the User’s hidden files and directories in /home on a remote server and mandating that those files be read from a remote location on boot.
AFAIK,
TSU