[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Janet Houser]

On 9/27/16 3:39 PM, Noriko Hosoi wrote:

On 09/27/2016 02:36 PM, Janet Houser wrote:



On 9/27/16 2:26 PM, Noriko Hosoi wrote:

On 09/27/2016 07:32 AM, Janet Houser wrote:



On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when 
trying to update a user's password via the command line.


I was able to change a password "as" the user via the 
command line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w 
current_user_passwd -s new_user_passwd 
"uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't 
update the password. In fact, after
issuing the following command (see below), both the old and 
new passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors 
when I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 
tag=97 nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts 
something into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds 
as the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left 
the general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy 
and tried to change the password via the command line and it 
worked!  I was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my 
domain and I could *still* change the password via the command 
line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized 
by removing and re-adding the policy.


I tested this procedure again this morning and removed my 
subtree password policy on my domain and re-added it. Things 
still work and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there's any info you'd like me to gather from my system for 
you to analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are using "ssh".


yes. I was ssh-ing to another LDAP 

Re: install linux with no Desktop (GUI)

[Bryon Adams]

On Sep 27, 2016 5:34 PM, Adel ESSAFI  wrote:
>
> Hello,
> I need to install fedora with only text mode available. I don t need 
> graphical desktop installed.
> Is there a way or an image that allows this?
>
> Regards
>
>
>
>
> --
> PhD candidate in Computer Science
> Address      
> 3 avenue lamine, cité ezzahra, Sousse 4000
> Tunisia
> tel: +216 97 246 706 (+33640302046 jusqu'au 15/6)
> fax: +216 71 391 166

I recommend using the net install / minimal image. I actually use it every 
time, even if I want the GUI. If you don't want to download all of the packages 
e dry time, the server install is the one you want.

Cheers___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: install linux with no Desktop (GUI)

[Samuel Sieb]

On 09/27/2016 02:34 PM, Adel ESSAFI wrote:

Hello,
I need to install fedora with only text mode available. I don t need
graphical desktop installed.
Is there a way or an image that allows this?

As long as you don't use a live image to install from, you can pick 
different options, including minimal.  The best one for you would most 
likely be the "Everything" net install image.


http://dl.fedoraproject.org/pub/fedora/linux/releases/24/Everything/x86_64/iso/
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: install linux with no Desktop (GUI)

[Earl A Ramirez]

Hello Adel,

Fedora Server has no GUI by default, you can give it a try.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/27/2016 02:36 PM, Janet Houser wrote:



On 9/27/16 2:26 PM, Noriko Hosoi wrote:

On 09/27/2016 07:32 AM, Janet Houser wrote:



On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying 
to update a user's password via the command line.


I was able to change a password "as" the user via the 
command line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd 
-s new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update 
the password. In fact, after
issuing the following command (see below), both the old and 
new passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors 
when I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 
tag=97 nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts 
something into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds 
as the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left 
the general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy 
and tried to change the password via the command line and it 
worked!  I was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my 
domain and I could *still* change the password via the command 
line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized 
by removing and re-adding the policy.


I tested this procedure again this morning and removed my 
subtree password policy on my domain and re-added it. Things 
still work and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there's any info you'd like me to gather from my system for 
you to analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are using "ssh".


yes. I was ssh-ing to another LDAP client.


Let me double check your steps.

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Janet Houser]

On 9/27/16 2:26 PM, Noriko Hosoi wrote:

On 09/27/2016 07:32 AM, Janet Houser wrote:



On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying 
to update a user's password via the command line.


I was able to change a password "as" the user via the command 
line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd 
-s new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update 
the password. In fact, after
issuing the following command (see below), both the old and 
new passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors 
when I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 
tag=97 nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts 
something into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds as 
the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left 
the general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy 
and tried to change the password via the command line and it 
worked!  I was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my 
domain and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized by 
removing and re-adding the policy.


I tested this procedure again this morning and removed my subtree 
password policy on my domain and re-added it. Things still work 
and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there's any info you'd like me to gather from my system for 
you to analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are using "ssh".


yes. I was ssh-ing to another LDAP client.


Let me double check your steps.

Using this example:
# ldapmodify -h 

install linux with no Desktop (GUI)

[Adel ESSAFI]

Hello,
I need to install fedora with only text mode available. I don t need
graphical desktop installed.
Is there a way or an image that allows this?

Regards




-- 
PhD candidate in Computer Science
Address
3 avenue lamine, cité ezzahra, Sousse 4000
Tunisia
tel: +216 97 246 706 (+33640302046 jusqu'au 15/6)
fax: +216 71 391 166
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/27/2016 07:32 AM, Janet Houser wrote:



On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying 
to update a user's password via the command line.


I was able to change a password "as" the user via the command 
line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd 
-s new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update 
the password. In fact, after
issuing the following command (see below), both the old and 
new passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when 
I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts something 
into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds as 
the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left 
the general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy 
and tried to change the password via the command line and it 
worked!  I was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my 
domain and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized by 
removing and re-adding the policy.


I tested this procedure again this morning and removed my subtree 
password policy on my domain and re-added it. Things still work and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there's any info you'd like me to gather from my system for you 
to analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are using "ssh".


yes. I was ssh-ing to another LDAP client.


Let me double check your steps.

Using this example:
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory 

Re: liveusb-creator

[Ranjan Maitra]

On 09/27/2016 09:32 AM, Chris Murphy wrote:
> This is an annoying thread.
>
> Ranjan, jd1008, Jon LaBadie - consider yourselves lucky the OP did not
> experience data loss as a result of obviously bad advice. Even my
> house plant recognized what treacherously bad advice it contained.
>
> The OP very clearly, without any ambiguity, expressed reluctance to
> use the CLI. And even after demonstrating dangerous lack of
> understanding with the dd command, you guys kept on pushing him
> forward. Seriously, it makes you three jerks. You're the guys who take
> the bunny slope skier on a blue/black run, and then when they get
> stuck or hurt you blame them for it. What is wrong with you? All three
> of you were also condescending, the bad advice wasn't enough
> apparently.
>
> I think Lawrence's thanks is pure charity. Next time someone clearly
> expresses such aversion, maybe consider having no advice at all? For
> all you know he could have rebooted at any point, and /dev/sda would
> have been enumerated as some other drive, and your advice would have
> resulted in data loss. All of your advice was unqualified.
>
> Honestly, hindsight being 20/20 you three really should realize how
> you just dodged a bullet, and so did Lawrence.
>
>
>
> Chris Murphy

I had stopped following this thread, but came across this accidentally. Btw, 
here is what my original post (after the OP expressed reluctance) said:

"Hi,

Unless I have misunderstood what you are trying to do, the steps are exactly 
what I have
written down. The only two things you have to fill out in the commandline are 
the if= and
the of= arguments. If you need help with that, please post back and we shall 
see if we can
help.

Best wishes,
Ranjan"

The OP never responded back.

Here is the original commandline steps mentioned in this e-mail:

begin cut-and-paste

# in order to make a bootable cd, etc, on the commandline:

sudo dd if=path-to-iso.iso of=/dev/sdb bs=1M

# In the above, if (input file) has path-to-iso.iso is the location of your 
iso. For
example: /tmp/Fedora.iso

# Note: only the letter-drive is to be included in the of (output file) i.e. 
/dev/sdb not
inclusive of the numeral /dev/sdb1.

end cut-and-paste

Perhaps you were just jumping in, but as far as I am concerned, I have been 
much helped on this forum since the days of Fedora Core 1, so I was only trying 
to help and offer encouragement for someone who was newer to Linux. This is how 
I learnt stuff in the first place.

I am sorry my post was interpreted otherwise.

And I missed his thanks, but I am grateful for that.

Best wishes,
Ranjan


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/manager

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: liveusb-creator

[jd1008]

On 09/26/2016 05:51 PM, Ed Greshko wrote:

On 09/27/16 07:21, Patrick O'Callaghan wrote:

On Tue, 2016-09-27 at 06:44 +0800, Ed Greshko wrote:

On 09/27/16 00:19, jd1008 wrote:

In case you are using the Nvidia proprietary driver proprietary driver, then
as Ed Greshko pointed out

I have not been involved in this thread and I made no such recommendation in 
regards to
hibernation.

I thought I must have missed something.


You didn't.  I have never used "suspend" or "hibernation" in the Linux 
environment.  So, I
know less than nothing about them.  So, if you read anything from me where I 
use words
like "hibernate" or "suspend" chances are that I'm talking about bears or 
inter-galactic
travel.



My bad - a mis-attribution.
Please see below:

On 09/26/2016 06:16 AM, jack smith wrote:

Don't know if it's related but there is a bug in Qt with the Nvidia drivers 
that break liveusb-creator.

https://bugzilla.redhat.com/show_bug.cgi?id=1356677
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: liveusb-creator

[jd1008]

On 09/27/2016 07:20 AM, fred roller wrote:


On Mon, Sep 26, 2016 at 11:14 PM, jd1008 > wrote:


But Rick, the OP was trying to dd into /dev/sda

How can it be that the system boots off of some disk that is not
/dev/sda,
and /dev/sda is empty? and is a usb flash???

Also, why would the op get a message to the effect "disk is full"
when it is a 32GB flash?

My suspicion is that it is not a USB disk, and that it is a very
old and small IDE disk.

-JD


If you look at my reply, he dd'd into a partition which I suspect was 
only 524Mb.  Odds are, as you mentioned, the system is probably hosed 
if in fact the it was a system drive.  An IDE would show as a "hd" 
[a,b,c,d]; hence the "ls" command to find the USB. If in fact he does 
have an IDE drive and it shows as "hd*" then it would explain the how 
the USB would be "sda" Alternatively he could use:


df -h

but I felt the output would have been too confusing until the OP could 
better understand.


Kevin, thanks for the clarification, was just keeping it simple.

-- Fred

Sometimes, it is hard to guide newbies because they do not understand 
the symbolic or place-holder kinds

of command arguments, just as an example.
He claimed he was running F24 - which could have been on sdb, and 
bootable from the boot sector of sda
via the grub config file on sdb?/boot/grub2/grub.cfg . As far as I know 
F24 does not create /dev/hd.. entries.

Thanx for clarifying
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: liveusb-creator

[jd1008]

Why did you not step up to the plate and provide
the OP with your two cent's worth?
We did all we could. The OP is a newbie and did not understand
the lingo we use to express command arguments. His GUI was
not working, so we provided an alternative...
Why did you not provide a perfectly working solution to his GUI problem?
The kettle calling the pot .etc


On 09/27/2016 09:32 AM, Chris Murphy wrote:

This is an annoying thread.

Ranjan, jd1008, Jon LaBadie - consider yourselves lucky the OP did not
experience data loss as a result of obviously bad advice. Even my
house plant recognized what treacherously bad advice it contained.

The OP very clearly, without any ambiguity, expressed reluctance to
use the CLI. And even after demonstrating dangerous lack of
understanding with the dd command, you guys kept on pushing him
forward. Seriously, it makes you three jerks. You're the guys who take
the bunny slope skier on a blue/black run, and then when they get
stuck or hurt you blame them for it. What is wrong with you? All three
of you were also condescending, the bad advice wasn't enough
apparently.

I think Lawrence's thanks is pure charity. Next time someone clearly
expresses such aversion, maybe consider having no advice at all? For
all you know he could have rebooted at any point, and /dev/sda would
have been enumerated as some other drive, and your advice would have
resulted in data loss. All of your advice was unqualified.

Honestly, hindsight being 20/20 you three really should realize how
you just dodged a bullet, and so did Lawrence.



Chris Murphy
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: resolution restricted after dnf update

[Gary Stainburn]

I tried all three available kernels - to no effect.

Once monitor was conected the the VGA port, the other connected via a VGA 
adaptor to the DVI port.

The odd thing is that once I swapped them over, the resolution problem went 
away.

Not only that, but although the login screen appeared on the wrong screen - as 
expected - once I was logged in, the primary screen was in the right place, 
and the mouse moves between them screens properly despite me not changing 
anything.

hay ho. It's fixed anyway

Thanks

On Monday 26 September 2016 19:20:51 Samuel Sieb wrote:
> On 09/26/2016 03:01 AM, Gary Stainburn wrote:
> > I could not see anything video related, but there was a kernel upgrade. I
> > tried booting on the previous kernel but it make no difference.
>
> Have you installed the NVidia driver or are you using nouveau?  What
> ports are the monitors using?  Is it possible to swap them?  I think you
> could use an xorg conf chunk to force it, but it would be good to fix it
> properly.
>
> It is odd that there were no graphics updates other than the kernel, but
> using an earlier kernel doesn't fix it.  Did you try both earlier
> kernels?  How long had it been since you rebooted the computer?
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org



-- 
Gary Stainburn
Group I.T. Manager
Ringways Garages
http://www.ringways.co.uk 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: liveusb-creator

[Chris Murphy]

This is an annoying thread.

Ranjan, jd1008, Jon LaBadie - consider yourselves lucky the OP did not
experience data loss as a result of obviously bad advice. Even my
house plant recognized what treacherously bad advice it contained.

The OP very clearly, without any ambiguity, expressed reluctance to
use the CLI. And even after demonstrating dangerous lack of
understanding with the dd command, you guys kept on pushing him
forward. Seriously, it makes you three jerks. You're the guys who take
the bunny slope skier on a blue/black run, and then when they get
stuck or hurt you blame them for it. What is wrong with you? All three
of you were also condescending, the bad advice wasn't enough
apparently.

I think Lawrence's thanks is pure charity. Next time someone clearly
expresses such aversion, maybe consider having no advice at all? For
all you know he could have rebooted at any point, and /dev/sda would
have been enumerated as some other drive, and your advice would have
resulted in data loss. All of your advice was unqualified.

Honestly, hindsight being 20/20 you three really should realize how
you just dodged a bullet, and so did Lawrence.



Chris Murphy
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Konsole title doesn't change

[Mark Haney]

Yep, that's precisely the problem I'm having.  I'll file a bug report now.
Thanks.


On Tue, Sep 27, 2016 at 10:29 AM, Ahmad Samir 
wrote:

> On 27 September 2016 at 15:36, Mark Haney 
> wrote:
> > For some reason, the latest Konsole package (konsole5-16.08.1-1.fc24.x86_
> 64)
> > has stopped updating the hostname on the title bar.  I've not changed the
> > profile info in the settings, so this is a bit of a mystery.
> >
> > Anyone else seen this problem?
> >
>
> Looks like this bug:
> https://bugs.kde.org/show_bug.cgi?id=368785
>
> which has been fixed in upstream git. (File a bug report to be sure
> the fix gets backported to f24).
>
> --
> Ahmad Samir
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>



-- 

Mark Haney ::: Senior Systems Engineer
*VIF* *International Education*
P.O. Box 3566 ::: Chapel Hill, N.C. 27515 ::: USA
919-265-5006 office

Global learning for all.
www.viflearn.com
Find VIF on Facebook  |
Twitter  | LinkedIn


Recognized as a ‘Best for the World’
 B Corp!
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Konsole title doesn't change

[Ahmad Samir]

On 27 September 2016 at 15:36, Mark Haney  wrote:
> For some reason, the latest Konsole package (konsole5-16.08.1-1.fc24.x86_64)
> has stopped updating the hostname on the title bar.  I've not changed the
> profile info in the settings, so this is a bit of a mystery.
>
> Anyone else seen this problem?
>

Looks like this bug:
https://bugs.kde.org/show_bug.cgi?id=368785

which has been fixed in upstream git. (File a bug report to be sure
the fix gets backported to f24).

--
Ahmad Samir
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Janet Houser]

On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying to 
update a user's password via the command line.


I was able to change a password "as" the user via the command 
line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update 
the password. In fact, after
issuing the following command (see below), both the old and new 
passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when 
I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts something 
into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds as 
the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left the 
general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy and 
tried to change the password via the command line and it worked!  I 
was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my domain 
and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized by 
removing and re-adding the policy.


I tested this procedure again this morning and removed my subtree 
password policy on my domain and re-added it. Things still work and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there's any info you'd like me to gather from my system for you 
to analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are using "ssh".


yes. I was ssh-ing to another LDAP client.


Let me double check your steps.

Using this example:
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> 

Konsole title doesn't change

[Mark Haney]

For some reason, the latest Konsole package
(konsole5-16.08.1-1.fc24.x86_64) has stopped updating the hostname on the
title bar.  I've not changed the profile info in the settings, so this is a
bit of a mystery.

Anyone else seen this problem?


-- 

Mark Haney ::: Senior Systems Engineer
*VIF* *International Education*
P.O. Box 3566 ::: Chapel Hill, N.C. 27515 ::: USA
919-265-5006 office

Global learning for all.
www.viflearn.com
Find VIF on Facebook  |
Twitter  | LinkedIn


Recognized as a ‘Best for the World’
 B Corp!
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: liveusb-creator

[fred roller]

On Mon, Sep 26, 2016 at 11:14 PM, jd1008  wrote:

> But Rick, the OP was trying to dd into /dev/sda
>
> How can it be that the system boots off of some disk that is not /dev/sda,
> and /dev/sda is empty? and is a usb flash???
>
> Also, why would the op get a message to the effect "disk is full"
> when it is a 32GB flash?
>
> My suspicion is that it is not a USB disk, and that it is a very old and
> small IDE disk.
>
> -JD
>

If you look at my reply, he dd'd into a partition which I suspect was only
524Mb.  Odds are, as you mentioned, the system is probably hosed if in fact
the it was a system drive.  An IDE would show as a "hd" [a,b,c,d]; hence
the "ls" command to find the USB. If in fact he does have an IDE drive and
it shows as "hd*" then it would explain the how the USB would be "sda"
Alternatively he could use:

df -h

but I felt the output would have been too confusing until the OP could
better understand.

Kevin, thanks for the clarification, was just keeping it simple.

-- Fred
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Annoying audit messages

[Patrick O'Callaghan]

On Tue, 2016-09-27 at 09:09 +0200, Jakub Jelen wrote:
> On 09/27/2016 02:22 AM, Alex wrote:
> > 
> > Hi,
> > 
> > On Mon, Sep 26, 2016 at 2:53 PM, Patrick O'Callaghan
> >  wrote:
> > > 
> > > On Mon, 2016-09-26 at 14:46 -0400, Alex wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > I recall seeing an rsyslog entry to prevent these messages from
> > > > filling my messages logs, but it no longer appears to work with f24.
> > > > Is there a more specific method to disable audit messages?
> > > > 
> > > > Sep 26 14:40:56 alex kernel: audit: type=2404
> > > > audit(1474915256.442:724): pid=3297 uid=0 auid=4294967295
> > > > ses=4294967295 msg='op=destroy kind=server
> > > > fp=SHA256:c3:77:02:0b:2c:82:43:05:c5:50:ff:e6:99:f1:3f:1a:1d:6a:51:b7:a4:cb:45:55:37:66:95:46:51:9b:80:d2
> > > > direction=? spid=3297 suid=0  exe="/usr/sbin/sshd" hostname=?
> > > > addr=107.155.77.2 terminal=? res=success'
> > > > 
> > > > I'm not using selinux, and have enabled rsyslog. They're just not 
> > > > helpful to me.
> > > Edit /etc/default/grub. Look for the line beginning GRUB_CMDLINE_LINUX.
> > > Add "audit=0" to the end of that line. Run:
> > > 
> > > grub2-mkconfig --output /boot/grub2/grub.cfg
> > > 
> > > Audit will be turned off when you reboot. To turn it off without
> > > rebooting, do:
> > > 
> > > auditctl -e 0
> > Thanks very much, very helpful. What is the reason this is enabled by
> > default? Don't other people find it obnoxious and unhelpful?
> > 
> > How does this information help the average sysadmin?
> Audit is not just a log. For that reason, it is not dumped to the same 
> files (/var/log/secure, /var/log/messages) as other logs, but into 
> separate file (/var/log/audit/audit.log), when you have auditd running 
> (if you stop that, it is dumped into the messages, which might be 
> confusing).
> 
> It keeps track of actions that were performed somewhere on lower level 
> than "average sysadmin" might need. In first place, they are needed for 
> the certifications in some environments. In second place, it is helpful 
> when you seek for more specific actions that were performed in the past.

I don't think anyone is against the idea of auditing per se. The
problem with the implementation is that a) audit lines overwhelm
everything else in the journal, and b) they are very hard to interpret
without a *lot* of background reading, i.e. they are genuinely useless
for most people other than professional sysadmins. Having them on by
default just means a huge waste of space and a good deal of
frustration.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

[389-users] Re: 389ds gets killed for memory usage

[Julian Kippels]

Hi Mark,

thank you for your suggestion. This has helped reducing the memory usage
tremendously.

Julian

On Mon, Sep 26, 2016 at 11:03:43AM -0400, Mark Reynolds wrote:
> Hi Julian,
> 
> I suggest you an alternative memory allocator (tcmalloc).
> 
> Install the "gperftools-libs" package.  Then edit /etc/sysconfig/dirsrv
> and add this line at the bottom:
> 
> LD_PRELOAD=/usr/lib64/libtcmalloc.so.4
> 
> If you are _not_ using systemd (but you probably are), then also add:
> "export LD_PRELOAD"
> 
> Restart the server, and you should see a significant improvement in
> memory size and growth.
> 
> Regards,
> Mark
> 
> 
> On 09/26/2016 04:02 AM, Julian Kippels wrote:
> > Hi,
> >
> > I have a setup with 3 Servers running on rhel7, 1 master and 2 slaves,
> > as described in the documentation chapter 11.2.1. Once or twice a week
> > the master gets killed by the OS because the system is out of memory. I
> > could just throw more ram at it, but the system already has 16GB of ram
> > and i would like to try to fix the problem without using more ressources
> > first. Can you give me any suggestions where to start looking? What do
> > you need from me to be able to help?
> >
> > Thanks
> > Julian
> > ___
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 

> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

Re: Annoying audit messages

[Jakub Jelen]

On 09/27/2016 02:22 AM, Alex wrote:

Hi,

On Mon, Sep 26, 2016 at 2:53 PM, Patrick O'Callaghan
 wrote:

On Mon, 2016-09-26 at 14:46 -0400, Alex wrote:

Hi all,

I recall seeing an rsyslog entry to prevent these messages from
filling my messages logs, but it no longer appears to work with f24.
Is there a more specific method to disable audit messages?

Sep 26 14:40:56 alex kernel: audit: type=2404
audit(1474915256.442:724): pid=3297 uid=0 auid=4294967295
ses=4294967295 msg='op=destroy kind=server
fp=SHA256:c3:77:02:0b:2c:82:43:05:c5:50:ff:e6:99:f1:3f:1a:1d:6a:51:b7:a4:cb:45:55:37:66:95:46:51:9b:80:d2
direction=? spid=3297 suid=0  exe="/usr/sbin/sshd" hostname=?
addr=107.155.77.2 terminal=? res=success'

I'm not using selinux, and have enabled rsyslog. They're just not helpful to me.

Edit /etc/default/grub. Look for the line beginning GRUB_CMDLINE_LINUX.
Add "audit=0" to the end of that line. Run:

grub2-mkconfig --output /boot/grub2/grub.cfg

Audit will be turned off when you reboot. To turn it off without
rebooting, do:

auditctl -e 0

Thanks very much, very helpful. What is the reason this is enabled by
default? Don't other people find it obnoxious and unhelpful?

How does this information help the average sysadmin?
Audit is not just a log. For that reason, it is not dumped to the same 
files (/var/log/secure, /var/log/messages) as other logs, but into 
separate file (/var/log/audit/audit.log), when you have auditd running 
(if you stop that, it is dumped into the messages, which might be 
confusing).


It keeps track of actions that were performed somewhere on lower level 
than "average sysadmin" might need. In first place, they are needed for 
the certifications in some environments. In second place, it is helpful 
when you seek for more specific actions that were performed in the past.


Your example shows an event, when the server private key was zeroed 
before exit or before changing to unprivileged process, who should not 
see the content of the private keys.


Regards,

--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org