hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
Thanks .
On 12/03/2013 02:08 PM, Jehan Procaccia wrote:
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
Two questions here: first, is there anything relevant in /var/log/messages? If so, it might tell you who ran useradd. Second, who, other than you, has either the root password or is in the wheel group?
On 03.12.2013 23:08, Jehan Procaccia wrote:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
Maybe there was no connection to LDAP server and gnome-initial-setup was presented to your pupils in order to make system usable. What happened next - you already know.
Remove gnome-initial setup package from your system to disable this back-door.
BTW. g-i-s lets you create user with admin privileges (wheel group). It's nothing unusual in "local" setups.
Mateusz Marzantowicz
On 12/03/2013 02:08 PM, Jehan Procaccia issued this missive:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
The system does want a local "administrator" account--one that's not dependent on the network (and hence LDAP) being available.
Normally the first-boot mechanism would create the "administrator" account once you've installed the system, but the username doesn't have to be "administrator" or "admin". It can be any name you want and this first user will be given administrator privileges (group "wheel"). The fact that the log entries indicate that this was done by "gnome-initial- setup" and the user was added to group "wheel" indicates that's exactly what happened.
It could be that someone ran gnome-initial-setup" manually. It's supposed to unlink from the systemd startup once it's complete, but I guess it could be run manually. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Always remember you're unique, just like everyone else. - ----------------------------------------------------------------------
On 12/03/2013 03:32 PM, poma wrote:
On 03.12.2013 23:08, Jehan Procaccia wrote:
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'//
Chick on wheels! Susann kick ass!
any suggestion greatly appreciated .
Marry her! As soon as possible!
poma
Do you have anything *relevant* to add to the discussion, or are you just here to waste bandwidth?
On 04.12.2013 00:44, Joe Zeff wrote:
On 12/03/2013 03:32 PM, poma wrote:
On 03.12.2013 23:08, Jehan Procaccia wrote:
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'//
Chick on wheels! Susann kick ass!
any suggestion greatly appreciated .
Marry her! As soon as possible!
poma
Do you have anything *relevant* to add to the discussion, or are you just here to waste bandwidth?
That *is* very *relevant*! Of course I'll translate it to you cause you did not understand quite, Mr. Bandwidth. Let *her* deal with these machines! Susann kick ass 2!
poma
On Dec 3, 2013, at 4:44 PM, Joe Zeff joe@zeff.us wrote:
On 12/03/2013 03:32 PM, poma wrote:
On 03.12.2013 23:08, Jehan Procaccia wrote:
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'//
Chick on wheels! Susann kick ass!
any suggestion greatly appreciated .
Marry her! As soon as possible!
poma
Do you have anything *relevant* to add to the discussion, or are you just here to waste bandwidth?
He appears to be the equivalent of Towelie. In that context, everything he writes here makes complete sense.
Chris Murphy
On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
See what running
/usr/libexec/gnome-initial-setup --force-new-user
does on one of your installed machines, where 'susana' has not been active before. Normally, it would prompt for the root password before creating a new account, but perhaps something else happens with your setup.
On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
See what running
/usr/libexec/gnome-initial-setup --force-new-user
does on one of your installed machines, where 'susana' has not been active before. Normally, it would prompt for the root password before creating a new account, but perhaps something else happens with your setup.
In the old days, a process called 'firstboot' was run immediately upon the first boot after a fresh install. firstboot was responsible for a number of things, but one of them was setting up the first user account and adding it to the "wheel" group because it was expected to be the administrator's account. firstboot never asked for the root password as it assumed it was being run as part of the install process by a human who installed the system and would already know the root password. Hence, the first user account was, by default, an administrative account in the wheel group who could sudo any command.
Once firstboot had been run, it disconnected itself from the boot process by deleting a file in the root of the filesystem that an init script looked for. If the file wasn't there, firstboot wouldn't run.
I don't run gnome (because it's so damned bloated), so I'm not sure what gnome-initial-setup does, but I suspect it took its cues from the old firstboot mechanism. If so, then what probably happened is that the install process was interrupted after the OS was installed. Whoever did the install did NOT go through the first boot. "susana" was probably the first person to see the machine, booted it and got the first boot thing. She added herself, not knowing exactly what this meant at the time. I doubt she was being malicious.
These are just guesses, mind you, but seem to be a likely scenario. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------
Le 04/12/2013 18:51, Rick Stevens a écrit :
On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
See what running
/usr/libexec/gnome-initial-setup --force-new-user
does on one of your installed machines, where 'susana' has not been active before. Normally, it would prompt for the root password before creating a new account, but perhaps something else happens with your setup.
In the old days, a process called 'firstboot' was run immediately upon the first boot after a fresh install. firstboot was responsible for a number of things, but one of them was setting up the first user account and adding it to the "wheel" group because it was expected to be the administrator's account. firstboot never asked for the root password as it assumed it was being run as part of the install process by a human who installed the system and would already know the root password. Hence, the first user account was, by default, an administrative account in the wheel group who could sudo any command.
Once firstboot had been run, it disconnected itself from the boot process by deleting a file in the root of the filesystem that an init script looked for. If the file wasn't there, firstboot wouldn't run.
I don't run gnome (because it's so damned bloated), so I'm not sure what gnome-initial-setup does, but I suspect it took its cues from the old firstboot mechanism. If so, then what probably happened is that the install process was interrupted after the OS was installed. Whoever did the install did NOT go through the first boot. "susana" was probably the first person to see the machine, booted it and got the first boot thing. She added herself, not knowing exactly what this meant at the time. I doubt she was being malicious.
These are just guesses, mind you, but seem to be a likely scenario.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
A day for firm decisions!!! Well, then again, maybe not! -
This senario is very possible we installed our station automatically (cobbler2 kickstart + cfengine3 for post config) and remotely , it is possible that some stations didn't finish correctly the install process and that the "firstboot" process didn't finished properly . Do you know how to check on a station if the "firstboot process" state is still "on" or "off", what about that mysterious file you mention "/it disconnected itself from the boot // //process by deleting a file in the root of the filesystem that an init // //script looked for. If the file wasn't there, firstboot wouldn't run./" what is its name ?
could this pb be relatated to: https://bugzilla.redhat.com/show_bug.cgi?id=968582 not sure, because on a station that has the pb it seems disabled:
# /bin/systemctl status initial-setup-text.service initial-setup-text.service - Initial Setup configuration program (text mode) Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service; disabled) Active: inactive (dead)
and I do run my kickstart with firstboot --disabled
if you have other suggestions on how to prevent my users to create local "wheel" account , let me know !
Thanks .
On 12/04/2013 01:42 PM, Jehan Procaccia issued this missive:
Le 04/12/2013 18:51, Rick Stevens a écrit :
On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
See what running
/usr/libexec/gnome-initial-setup --force-new-user
does on one of your installed machines, where 'susana' has not been active before. Normally, it would prompt for the root password before creating a new account, but perhaps something else happens with your setup.
In the old days, a process called 'firstboot' was run immediately upon the first boot after a fresh install. firstboot was responsible for a number of things, but one of them was setting up the first user account and adding it to the "wheel" group because it was expected to be the administrator's account. firstboot never asked for the root password as it assumed it was being run as part of the install process by a human who installed the system and would already know the root password. Hence, the first user account was, by default, an administrative account in the wheel group who could sudo any command.
Once firstboot had been run, it disconnected itself from the boot process by deleting a file in the root of the filesystem that an init script looked for. If the file wasn't there, firstboot wouldn't run.
I don't run gnome (because it's so damned bloated), so I'm not sure what gnome-initial-setup does, but I suspect it took its cues from the old firstboot mechanism. If so, then what probably happened is that the install process was interrupted after the OS was installed. Whoever did the install did NOT go through the first boot. "susana" was probably the first person to see the machine, booted it and got the first boot thing. She added herself, not knowing exactly what this meant at the time. I doubt she was being malicious.
These are just guesses, mind you, but seem to be a likely scenario.
This senario is very possible we installed our station automatically (cobbler2 kickstart + cfengine3 for post config) and remotely , it is possible that some stations didn't finish correctly the install process and that the "firstboot" process didn't finished properly . Do you know how to check on a station if the "firstboot process" state is still "on" or "off", what about that mysterious file you mention "/it disconnected itself from the boot // //process by deleting a file in the root of the filesystem that an init // //script looked for. If the file wasn't there, firstboot wouldn't run./" what is its name ?
On old systems (e.g. CentOS 5/6), the /etc/rc.d/init.d/firstboot script looked for an /etc/sysconfig/firstboot file. That file would contain either
RUN_FIRSTBOOT=YES
to run firstboot, or
RUN_FIRSTBOOT=NO
so it didn't run. Also, if the /etc/reconfigSys file was present, then firstboot would be run with the "--reconfig" option.
Again, I don't run gnome (I'm an XFCE user) so I don't know if it's a systemd service that should run and then remove itself or what. To be honest, I haven't done a fresh Fedora installation (F18 or F19) in a while (I've "fedup"ped already installed systems).
could this pb be relatated to: https://bugzilla.redhat.com/show_bug.cgi?id=968582 not sure, because on a station that has the pb it seems disabled:
# /bin/systemctl status initial-setup-text.service initial-setup-text.service - Initial Setup configuration program (text mode) Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service; disabled) Active: inactive (dead)
It'd be interesting to bring up a system and see if that service is set to start on the first boot after an install.
and I do run my kickstart with firstboot --disabled
That may not have an effect as I don't think there is a "firstboot" thing since we went to systemd/systemctl rather than the classic init scripts. I think that initial-setup-text.service and/or the gnome-initial-setup thing may have replaced that. Since I never installed Gnome, I don't have the gnome-initial-setup program nor do I seem to have a initial-setup-text.service file.
I wish I could be of more help. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - UNIX is actually quite user friendly. The problem is that it's - - just very picky of who its friends are! - ----------------------------------------------------------------------
Le 04/12/2013 23:04, Rick Stevens a écrit :
On 12/04/2013 01:42 PM, Jehan Procaccia issued this missive:
Le 04/12/2013 18:51, Rick Stevens a écrit :
On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
hello I use about a hundred fedora19 stations in computer labs at our school users accounts comes from an ldap directory and the homedir is automounted via NFS. However, recently I noticed that on some stations, local user account had been created ! looking at the log file, I discovered in /var/log/secure something like this:
/accounts-daemon: request by system-bus-name ::1.733 [/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user 'foobar'// //useradd[29724]: new group: name=foobar, GID=1001// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user: name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to group 'wheel'// //secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever add them to the wheel group ! could it be a bug in /gnome-initial-setup , /a feature side effect ? or our students found a "back door" ? any suggestion greatly appreciated .
See what running
/usr/libexec/gnome-initial-setup --force-new-user
does on one of your installed machines, where 'susana' has not been active before. Normally, it would prompt for the root password before creating a new account, but perhaps something else happens with your setup.
In the old days, a process called 'firstboot' was run immediately upon the first boot after a fresh install. firstboot was responsible for a number of things, but one of them was setting up the first user account and adding it to the "wheel" group because it was expected to be the administrator's account. firstboot never asked for the root password as it assumed it was being run as part of the install process by a human who installed the system and would already know the root password. Hence, the first user account was, by default, an administrative account in the wheel group who could sudo any command.
Once firstboot had been run, it disconnected itself from the boot process by deleting a file in the root of the filesystem that an init script looked for. If the file wasn't there, firstboot wouldn't run.
I don't run gnome (because it's so damned bloated), so I'm not sure what gnome-initial-setup does, but I suspect it took its cues from the old firstboot mechanism. If so, then what probably happened is that the install process was interrupted after the OS was installed. Whoever did the install did NOT go through the first boot. "susana" was probably the first person to see the machine, booted it and got the first boot thing. She added herself, not knowing exactly what this meant at the time. I doubt she was being malicious.
These are just guesses, mind you, but seem to be a likely scenario.
This senario is very possible we installed our station automatically (cobbler2 kickstart + cfengine3 for post config) and remotely , it is possible that some stations didn't finish correctly the install process and that the "firstboot" process didn't finished properly . Do you know how to check on a station if the "firstboot process" state is still "on" or "off", what about that mysterious file you mention "/it disconnected itself from the boot // //process by deleting a file in the root of the filesystem that an init // //script looked for. If the file wasn't there, firstboot wouldn't run./" what is its name ?
On old systems (e.g. CentOS 5/6), the /etc/rc.d/init.d/firstboot script looked for an /etc/sysconfig/firstboot file. That file would contain either
RUN_FIRSTBOOT=YESto run firstboot, or
RUN_FIRSTBOOT=NOso it didn't run. Also, if the /etc/reconfigSys file was present, then firstboot would be run with the "--reconfig" option.
Again, I don't run gnome (I'm an XFCE user) so I don't know if it's a systemd service that should run and then remove itself or what. To be honest, I haven't done a fresh Fedora installation (F18 or F19) in a while (I've "fedup"ped already installed systems).
could this pb be relatated to: https://bugzilla.redhat.com/show_bug.cgi?id=968582 not sure, because on a station that has the pb it seems disabled:
# /bin/systemctl status initial-setup-text.service initial-setup-text.service - Initial Setup configuration program (text mode) Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service; disabled) Active: inactive (dead)
It'd be interesting to bring up a system and see if that service is set to start on the first boot after an install.
and I do run my kickstart with firstboot --disabled
That may not have an effect as I don't think there is a "firstboot" thing since we went to systemd/systemctl rather than the classic init scripts. I think that initial-setup-text.service and/or the gnome-initial-setup thing may have replaced that. Since I never installed Gnome, I don't have the gnome-initial-setup program nor do I seem to have a initial-setup-text.service file.
I wish I could be of more help.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- UNIX is actually quite user friendly. The problem is that it's -
just very picky of who its friends are! -
yes I suspect that in F19 the "firstboot" machnism might have change a lot from older versions
my kicstart file is programmed to set a root password and create a local user account, Although I set in the kickstart file firstboot --disabled I took that option from a older kickstart (F13 I think) installed, and maybe it has not the exepected effect anymore ...
perhaps there had been a strange set of events that prevented the install process to terminate properly,
Anyway, /usr/libexec/gnome-initial-setup can be run anytime be any user, but I am expecting that unprivilege user cannot add local users ! on a machine that is installed properly , it allows unprivilege users only to create "remote = google, facebook ..." accounts, not local .
Is someone on the list, knows what is the status of "firstboot" process on F19 machines ? how can I check its state ?
would remove gnome-initial-setup package be a solution without bad side effect ?
Thanks .
On 04.12.2013 23:35, Jehan Procaccia wrote:
would remove gnome-initial-setup package be a solution without bad side effect ?
Yes, you can safely remove this package without any negative consequences. I did it in the past on some network managed boxes and all those systems work perfectly. I have local root account configured just in case dirserv is unavailable or some other error happens.
Mateusz Marzantowicz
On 05.12.2013 16:24, Mateusz Marzantowicz wrote:
On 04.12.2013 23:35, Jehan Procaccia wrote:
would remove gnome-initial-setup package be a solution without bad side effect ?
Yes, you can safely remove this package without any negative consequences. I did it in the past on some network managed boxes and all those systems work perfectly. I have local root account configured just in case dirserv is unavailable or some other error happens.
Mateusz Marzantowicz
http://www.youtube.com/watch?v=mQqy-XP-6KQ Haha
poma
On 05.12.2013 16:31, poma wrote:
On 05.12.2013 16:24, Mateusz Marzantowicz wrote:
On 04.12.2013 23:35, Jehan Procaccia wrote:
would remove gnome-initial-setup package be a solution without bad side effect ?
Yes, you can safely remove this package without any negative consequences. I did it in the past on some network managed boxes and all those systems work perfectly. I have local root account configured just in case dirserv is unavailable or some other error happens.
Mateusz Marzantowicz
http://www.youtube.com/watch?v=mQqy-XP-6KQ Haha
poma
:-)
[...] Again I sit myself beside her Try to take her hand in mine The moment's gone, the feeling's over She looks around to find the time Then she says could we just sit and chat And I think well that's that [...]
Mateusz Marzantowicz
-
Chris Murphy -
David -
jehan procaccia -
Joe Zeff -
Mateusz Marzantowicz -
Michael Schwendt -
poma -
Rick Stevens