Monday, 24 August 2020

Important command

 for Windows

Command

wmic bios get serialnumber


Posted by at No comments:

Node Manager Username and Password for Oracle HTTP Server 12c

 

How to Change the Node Manager Username and Password for Oracle HTTP Server 12c in a Standalone Domain (Doc ID 1945039.1)

Applies to:

Oracle HTTP Server - Version 12.1.2.0.0 and later
Information in this document applies to any platform.

Goal

What tools can be used to modify the node manager user name and password for a standalone OHS 12c domain?  

Note:  A standalone domain is a container for system components, such as Oracle HTTP Server. It has a directory structure similar to an Oracle WebLogic Server Domain, but it does not contain an Administration Server or Managed Servers. It can contain one or more instances of system components of the same type, such as Oracle HTTP Server, or a mix of system component types.  Reference 1.4.2 Standalone Domain

 

Solution

The steps are as follows:

1. Stop the Oracle HTTP Server component and the Node Manager (NM) :

$ cd DOMAIN_HOME/bin
$ ./stopComponent.sh <ohs_component>

$ ./stopComponent.sh <ohs_component>
Stopping System Component <ohs_component> ...

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Reading domain from DOMAIN_HOME
 
Please enter your password : <Enter old password>
Connecting to Node Manager ...
Successfully Connected to Node Manager.
Killing server <ohs_component> ...
Successfully killed server <ohs_component>
Successfully disconnected from Node Manager.

Exiting WebLogic Scripting Tool.

Done
$

CTRL C in the window where NM is running (Or kill the PID of NM)


2. Invoke WLST offline:

$ cd ORACLE_HOME/oracle_common/common/bin
$ ./wlst.sh

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline>

3. Read in the domain:

wls:/offline>readDomain('DOMAIN_HOME')

4. Get the security MBean:

wls:/offline/ohs_domain>cd('/SecurityConfiguration/ohs_domain')

5. Change the NM user name:
Need to provide a node manager user name on this step, this can be an old user name. Otherwise, the NM password may not modify correctly.

wls:/offline/new_ohs_domain/SecurityConfiguration/new_ohs_domain>set('NodeManagerUsername','<new_NM_Username>')

6. Change the NM password then commit the changes. You can give a clear text password such as 'welcome1'.
The encrypted password will be stored in /u01/oracle/config/ohs_domain/nodemanager/nm_password.properties.

wls:/offline/new_ohs_domain/SecurityConfiguration/new_ohs_domain>set('NodeManagerPasswordEncrypted','password')
wls:/offline/new_ohs_domain/SecurityConfiguration/new_ohs_domain>updateDomain()
wls:/offline/new_ohs_domain/SecurityConfiguration/new_ohs_domain>closeDomain()
wls:/offline>exit()

Exiting WebLogic Scripting Tool.


Checking timestamps you can see that  the following files have been updated:

/u01/oracle/config/ohs_domain/config/config.xml
/u01/oracle/config/ohs_domain/config/nodemanager/nm_password.properties

7. Restart NM:

$ cd DOMAIN_HOME/bin
$ ./startNodeManager.sh

8. Finally, restart OHS

$ ./startComponent.sh <ohs_component>
Starting System Component <ohs_component> ...

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Reading domain from DOMAIN_HOME
 
Please enter your password : <Enter new password>
Connecting to Node Manager ...
Successfully Connected to Node Manager.
Starting server <ohs_component> ...
Successfully started server <ohs_component> ...
Successfully disconnected from Node Manager.

Exiting WebLogic Scripting Tool.

Done


9. It is possible to prevent the prompt for the NM password on each OHS startup by storing the password in an encrypted form using a key store with the command:

$ ./startComponent.sh <ohs_component> storeUserConfig

10. If the old password was previously stored in a key store before the password was changed, the cached key store files need to be removed before restarting the OHS component:

$ cd
$ cd .wlst
$ ls -l
total 8
-rw-r----- 1 user group 227 Nov 14 16:09 nm-cfg-ohs_domain.props
-rw-r----- 1 user group 64 Nov 14 16:09 nm-key-ohs_domain.props
$ rm nm-cfg-ohs_domain.props
$ rm nm-key-ohs_domain.props


11. If required, the new password can then be re-stored using the same command:

$ ./startComponent.sh <ohs_component> storeUserConfig
To BottomTo Bottom
Posted by at No comments:

Wednesday, 12 August 2020

Adding to Root Group using usermod

 

Method  1: Adding to Root Group using usermod

Let see how we can grant normal user root access by adding to root group.

# adduser user1
# adduser user2
# groupadd test

These are the groups I have in my Linux box.

# groups
root bin daemon sys adm disk wheel

I am going to add user1 to root group as follows:

# usermod -G root user1

The command given below provides the existing user with the root privilege

# usermod -g 0 -o root_user

Method 2: Adding to Root Group using Useradd Command

I have added a new user, 'user3' to the root group using one single command:

# useradd -m -G root user3
# groups user3
user3 : user3 root

Another option using useradd command

useradd -c “Imitation Root” -d /home/root_user -m -k /etc/skel -s /bin/bash -u 0 -o -g root root_user

Method 3: Editing /etc/passwd file

Edit /etc/passwd for the particular user. Change the user's UID and GID to '0'. This will give root permissions to user.

root:x:0:0:root:/root:/bin/bash
temproot:x:128:128:temproot

Now, temproot user should have root privilege:

root:x:0:0:root:/root:/bin/bash
temproot:x:0:0:temproot

Note: This is not the recommended method for granting root access

Method 4: Setting as Sudo User

The sudo configuration file is /etc/sudoers and you can edit this file using visudo command: # visudo.

Using visudo protects from conflicts and guarantees that the right syntax is used.

To give full access to specific users

Add the entry given below in the file:

bob, tom ALL=(ALL) ALL

Following this method is not a good idea because this allows both bob and tom to use the su command to grant themselves permanent root privileges. Thereby skipping the command logging features of sudo.

Granting access to specific files to one particular user

This entry allows bob and all the other members of the group operator to gain access to all the program files in the /sbin and /usr/sbin directories, as well as the privilege of running the command /usr/oracle/backup.pl.

bob, %operator ALL= /sbin/, /usr/sbin, /usr/oracle/backup.pl

If you have any questions or thoughts to share on this topic, use the feedback form.

Posted by at No comments:

Monday, 27 July 2020

Displaying Password Information in solaris 11


You can use the passwd command to display password information about all users in a domain or about one particular user:
For your password information

passwd -s
For all users in current domain

passwd -s -a
For a particular user

passwd -s username
Only the entries and columns for which you have read permission will be displayed. Entries are displayed with the following format:
  • Without password aging: username status
  • With password aging: username status mm/dd/yy min max warn expire inactive
Table 11-4 NIS+ Password Display Format
Field
 Description
 For Further Information
username
The user's login name.
status
The user's password status. PS indicates the account has a password. LK indicates the password is locked. NP indicates the account has no password.
 See "Locking a Password".
mm/dd/yy
The date, based on Greenwich mean time, that the user's password was last changed.
min
The minimum number of days since the last change that must pass before the password can be changed again.
 See "Setting Minimum Password Life".
max
The maximum number of days the password can be used without having to change it.
 See "Setting a Password Age Limit".
warn
The number of days' notice that users are given before their passwords have to be changed.
 See "Establishing a Warning Period".
expire
A date on which users loose the ability to log in to their accounts.
 See "Password Privilege Expiration".
inactive
A limit on the number of days that an account can go without being logged in to. Once that limit is passed without a log in users can no longer access their accounts.
 See "Specifying Maximum Number of Inactive Days".

To display entries from a passwd table in another domain, use the -D option:
For all users in another domain

passwd -s -a -D domainname
For a particular user

passwd -s -D domainname username 
 
 

Changing Passwords

New passwords must meet the criteria described in "Password Requirements".

Changing Your Own Password

To change your password, type

station1% passwd
You will be prompted for your old password and then the new password and then the new password a second time to confirm it.

Changing Someone Else's Password

To change someone else' password, use:
To change another user's password in the same domain

passwd username
To change another user's password in a different domain

passwd -D domainname username
When using the passwd command in an NIS+ environment (see "The passwd Command and "NIS+ Environment"") to change someone else's password you must have modify rights to that user's entry in the passwd table (this usually means that you are a member of the group for the passwd table and the group has modify rights). You do not have to enter either the user's old password or your password. You will be prompted to enter the new password twice to make sure that they match. If they do not match, you will be prompted to enter them again.

Changing Root's Password

When changing root's password, you must always run chkey -p immediately after changing the password with the passwd command. Failure to run chkey -p after changing root's password will result in root being unable to properly log in.
To change a root password, follow these steps:
  1. Log in as root.
  2. Change root's password using passwd.
    Do not use nispasswd.
  3. Run chkey -p.
    You must use the -p option.

Locking a Password

When operating in an NIS+ environment (see "The passwd Command and "NIS+ Environment""), an administrator (a group member) with modify rights to a user's entry in the passwd table can use the passwd command to lock a password. An account with a locked password cannot be used. When a password is locked, the user will receive a Login incorrect message after each login attempt.
Keep in mind that locked passwords have no effect on users who are already logged in. A locked password only prevents users from performing those operations that require giving a password such as login, rlogin, ftp, or telnet.
Note also that if a user with a locked password is already logged in, and that user uses the passwd command to change passwords, the lock is broken.
You can use this feature to:
  • Temporarily lock a user's password while that user is on vacation or leave. This prevents anyone from logging in as the absent user.
  • Immediately lock one or more user passwords in the case of suspected security problem.
  • Quickly lock a dismissed employee out of the system. This is quicker and easier than eliminating that user's account and is an easy way of preserving any data stored in that account.
  • If you have assigned passwords to UNIX processes, you can lock those passwords. This allows the process to run, but prevents anyone from logging in as those processes even if they know the process password. (In most cases, processes would not be set up as NIS+ principals, but would maintain their password information in /etc files. In such a case you would have to run the passwd command in files mode to lock /etc stored passwords.)
To lock a password, use:

passwd -l username

Unlocking a Password

To unlock a user's password, you simply change it. You can "change" it back to the exact same password that it was when it was locked. Or you can change it to something new.
For example, to unlock jody's password, you would enter:

station1% passwd jody

Managing Password Aging

Password aging is a mechanism you can use to force users to periodically change their passwords.
Password aging allows you to:
  • Force a user to choose a new password the next time the user logs in. (See "Forcing Users to Change Passwords" for details.)
  • Specify a maximum number of days that a password can be used before it has to be changed. (See "Setting a Password Age Limit" for details.)
  • Specify a minimum number of days that a password has to be in existence before it can be changed. (See "Setting Minimum Password Life" for details.)
  • Specify that a warning message be displayed whenever a user logs in a specified number of days before the user's password time limit is reached. (See "Establishing a Warning Period" for details.)
  • Specify a maximum number of days that an account can be inactive. If that number of days pass without the user logging in to the account, the user's password will be locked. (See "Specifying Maximum Number of Inactive Days" for details.)
  • Specify an absolute date after which a user's password cannot be used, thus denying the user the ability to log on to the system. (See "Password Privilege Expiration" for details.)
Keep in mind that users who are already logged in when the various maximums or dates are reached are not affected by the above features. They can continue to work as normal.
Password aging limitations and activities are only activated when a user logs in or performs one of the following operations:
  • login
  • rlogin
  • telnet
  • ftp
These password aging parameters are applied on user-by-user basis. You can have different password aging requirements for different users. (You can also set general default password aging parameters as described in "Managing Password Aging".)

Forcing Users to Change Passwords

There are two ways to force a user to change passwords the next time the user logs in:
Force change keeping password aging rules in effect

passwd -f username
Force change and turn off password aging rules

passwd -x 0 username

Setting a Password Age Limit

The -max argument to the passwd command sets an age limit for the current password. In other words, it specifies the number of days that a password remains valid. After that number of days, a new password must be chosen by the user. Once the maximum number of days have passed, the next time the user tries to login with the old password a Your password has been expired for too long message is displayed and the user is forced to choose a new password in order to finish logging in to the system.
The max argument uses the following format:

passwd -x max username
Where:
  • username is the login ID of the user
  • max is one of the following values:
    • Greater than zero. Any number greater than zero sets that number of days before the password must be changed.
    • Zero (0). A value of zero (0) forces the user to change passwords the next time the user logs in, and it then turns off password aging.
    • Minus one (-1). A value of minus one (-1) turns off password aging. In other words, entering passwd -x -1 username cancels any previous password aging applied to that user.
For example, to force the user schweik to change passwords every 45 days, you would type the command:

station1% passwd -x 45 schweik

Setting Minimum Password Life

The min argument to the passwd command specifies the number of days that must pass before a user can change passwords. If a user tries to change passwords before the minimum number of days has passed, a Sorry less than N days since the last change message is displayed.
The min argument uses the following format:

passwd -x max -n min username
Where:
  • username is the login ID of the user
  • max is the maximum number of days a password is valid as described in the section above
  • min is the minimum number of days that must pass before the password can be changed.
For example, to force the user eponine to change passwords every 45 days, and prevent him from changing it for the first 7 days you would type the command:

station1% passwd -x 45 -n 7 eponine
The following rules apply to the min argument:
  • You do not have to use a min argument or specify a minimum number of days before a password can be changed.
  • If you do use the min argument, it must always be used in conjunction with the -max argument. In other words, in order to set a minimum value you must also set a maximum value.
  • If you set min to be greater than max, the user is unable to change passwords at all. For example, the command passwd -x 7 -n 8 prevents the user from changing passwords. If the user tries to change passwords, the You may not change this password message is displayed. Setting the min value greater than the max value has two effects:
    • The user is unable to change password. In this case, only someone with administer privileges could change the password. For example, in situations where multiple users share a common group password, setting the min value for that password greater than the max value would prevent any individual user from changing the group password.
    • The password is only valid for the length of time set by the max value, but the user cannot change it because the min value is greater than the max value. Thus, there is no way for the user to prevent the password from becoming invalid at the expiration of the max time period. In effect, this prevents the user from logging in after the max time period unless an administrator intervenes.

Establishing a Warning Period

The warn argument to the passwd command specifies the number of days before a password reaches its age limit that users will start to seeing a Your password will expire in N days message (where N is the number of days) when they log in.
For example, if a user's password has a maximum life of 30 days (set with the -max argument) and the warn value is set to 7 days, when the user logs in on the 24th day (one day past the warn value) the warning message Your password will expire in 7 days is displayed. When the user logs in on the 25th day the warning message Your password will expire in 6 days is displayed.
Keep in mind that the warning message is not sent by Email or displayed in a user's console window. It is displayed only when the user logs in. If the user does not log in during this period, no warning message is given.
Keep in mind that the warn value is relative to the max value. In other words, it is figured backwards from the deadline set by the max value. Thus, if the warn value is set to 14 days, the Your password will expire in N days message will begin to be displayed two weeks before the password reaches its age limit and must be changed.
Because the warn value is figured relative to the max value, it only works if a max value is in place. If there is no max value, warn values are meaningless and are ignored by the system.
The warn argument uses the following format:

passwd -x max -w warn username
Where:
  • username is the login ID of the user.
  • max is the maximum number of days a password is valid as described on "Setting a Password Age Limit".
  • warn is the number of days before the password reaches its age limit that the warning message will begin to be displayed.
For example, to force the user nilovna to change passwords every 45 days, and display a warning message 5 days before the password reaches its age limit you would type the command:

station1% passwd -x 45 -w 5 nilovna
The following rules apply to the warn argument:
  • You do not have to use the warn argument or specify a warning message. If no warn value is set, no warning message is displayed prior to a password reaching its age limit.
  • If you do use the warn argument, it must always be used in conjunction with the max argument. In other words, in order to set a warning value you must also set a maximum value.
Note - You can also use Solstice AdminSuiteTM to set a warn value for a user's password.

Turning Off Password Aging

There are two ways to turn off password aging for a given user:
Turn off aging while allowing user to retain current password

passwd -x -1 username
Force user to change password at next login, and then turn off aging 

passwd -x 0 username
This sets the max value to either zero or -1 (see "Setting a Password Age Limit" for more information on this value).
For example, to force the user mendez to change passwords the next time he logs in and then turn off password aging you would type the command:

station% passwd -x 0 mendez
Note - You can also use Solstice AdminSuiteTM to set this parameter for a user's password.
You can also use the nistbladm command to set this value. For example, to turn off password aging for the user otsu and allow her to continue using her current password, you would type: 

station1% nistbladm -m `shadow=0:0:-1:0:0:0:0' [name=otsu],passwd.org_dir
For additional information on using the nistbladm command, see "The nistbladm Command".

Password Privilege Expiration

You can set a specific date on which a user's password privileges expires. When a user's password privilege expires, that user can no longer have a valid password at all. In effect, this locks the user out of the system after the given date because after that date the user can no longer log in.
For example, if you specify an expire date of December 31, 1997, for a user named pete, on January 1, 1998 he will not be able to log in under that user ID regardless of what password he uses. After each login attempt he will receive a Login incorrect message.

Password Aging Versus Expiration

Expiration of a user's password privilege is not the same as password aging.
  • Password aging. A password that has not been changed for longer than the aging time limit is sometimes referred to as an expired password. But that password can still be used to log in one more time. As part of that last login process the user is forced to choose a new password.
  • Expiration of password privilege. When a user's password privilege expires, the user cannot log in at all with any password.) In other words, it is the user's permission to log in to the network that has expired.

Setting an Expiration Date

Password privilege expiration dates only take effect when the user logs in. If a user is already logged in, the expiration date has no affect until the user logs out or tries to use rlogin or telnet to connect to another machine at which time the user will not be able to log in again. Thus, if you are going to implement password privilege expiration dates, you should require your users to log out at the end of each day's work session.
Note - If you have Solstice AdminSuiteTM tools available, do not use nistbladm to set an expiration date. Use Solstice AdminSuiteTM tools because they are easier to use and provide less chance for error.
To set an expiration date with the nistbladm command: 

nistbladm -m `shadow=n:n:n:n:n:n6:n' [name=login],passwd.org_dir
Where:
  • login is the user's login ID
  • n indicates the values in the other fields of the shadow column.
  • n6 is the date on which the user's password privilege expires. This date is entered as a number of days since January 1, 1970 (see Table 11-2). n6 can be one of the following values:
    • Minus one (-1). A value of minus one (-1) turns off the expiration feature. If a user's password has already expired, changing this value to -1 restores (un-expires) it. If you do not want to set any expiration date, type -1 in this field.
    • Greater than zero. A value greater than zero sets the expiration date to that number of days since 1/1/70. If you enter today's date or earlier, you immediately expire the user's password.
For example, to specify an expiration date for the user pete of December 31, 1995 you would type:

station1% nistbladm -m `shadow=n:n:n:n:n:9493:n' [name=pete],passwd.org_dir
Caution - Caution - All of the fields must be filled in with valid values.

Turning Off Password Privilege Expiration

To turn off or deactivate password privilege expiration, you must use the nistbladm command to place a -1 in this field. For example, to turn off privilege expiration for the user huck, you would type:

station1% nistbladm -m `shadow=n:n:n:n:n:-1:n' [name=huck],passwd.org_dir
Or you can use the nistbladm command reset the expiration date to some day in the future by entering a new number of days in the n6 field.

Specifying Maximum Number of Inactive Days

You can set a maximum number of days that a user can go without logging in on a given machine. Once that number of days passes without the user logging in, that machine will no longer allow that user to log in. In this situation, the user will receive a Login incorrect message after each login attempt.
This feature is tracked on a machine-by-machine basis, not a network-wide basis. That is, in an NIS+ environment, you specify the number of days a user can go without logging in by placing an entry for that user in the passwd table of the user's home domain. That number applies for that user on all machines on the network.
For example, suppose you specify a maximum inactivity period of 10 days for the user sam. On January 1, sam logs in to both machine-A and machine-B, and then logs off both machines. Four days later on January 4, sam logs in on machine-B and then logs out. Nine days after that on January 13, sam can still log in to machine-B because only 9 days have elapsed since the last time he logged in on that machine, but he can no longer log in to machine-A because thirteen days have passed since his last log in on that machine.
Keep in mind that an inactivity maximum cannot apply to a machine the user has never logged in to. No matter what inactivity maximum has been specified or how long it has been since the user has logged in to some other machine, the user can always log in to a machine that the user has never logged in to before.
Caution - Caution - Do not set inactivity maximums unless your users are instructed to log out at the end of each workday. The inactivity feature only relates to logins; it does not check for any other type of system use. If a user logs in and then leaves the system up and running at the end of each day, that user will soon pass the inactivity maximum because there has been no login for many days. When that user finally does reboot or log out, he or she won't be able to log in.
Note - If you have Solstice AdminSuiteTM tools available, do not use nistbladm to set an inactivity maximum. Use Solstice AdminSuite tools because they are easier to use and provide less chance for error.
To set a login inactivity maximum, you must use the nistbladm command in the format: 

nistbladm -m `shadow=n:n:n:n:n5:n:n' [name=login],passwd.org_dir
Where:
  • login is the user's login ID
  • n indicates the values in the other fields of the shadow column.
  • n5 is the number of days the user is allowed to go between logins. Inactive can be one of the following values:
    • Minus one (-1). A value of minus one (-1) turns off the inactivity feature. The user can be inactive for any number of days without losing login privileges. This is the default.
    • Greater than zero. A value greater than zero sets the maximum inactive period to that number of days.
For example, to specify that the user sam must log in at least once every seven days, you would type:

station1% nistbladm -m `shadow=n:n:n:n:n:7:n:n' [name=sam],passwd.org_dir
To clear an inactivity maximum and allow a user who has been prevented from logging in to log in again, use nistbladm to set the inactivity value to -1.

Specifying Password Criteria and Defaults

The following subsections describe various password-related defaults and general criteria that you can specify.

The /etc/defaults/passwd File

The /etc/defaults/passwd file is used to set four general password defaults for users whose nsswitch.conf file points to files. The defaults set by the /etc/defaults/passwd file apply only to those users whose operative password information is taken from /etc files; they do not apply to anyone using either NIS maps or NIS+ tables. An /etc/defaults/passwd file on an NIS+ server only affects local users who happen to be obtaining their password information from those local files. An /etc/defaults/passwd file on an NIS+ server has no effect on the NIS+ environment or users whose nsswitch.conf file points to either nis or nisplus.
The four general password defaults governed by the /etc/defaults/passwd file are:
  • Maximum number of weeks the password is valid
  • Minimum number of weeks the password is valid
  • The number of weeks before the password becomes invalid that the user is warned
  • The minimum number of characters that a password must contain
The following principles apply to defaults set with an /etc/defaults/passwd file:
  • For users who obtain password information from local /etc files, individual password aging maximums, minimums and warnings set by the password command or Solstice AdminSuite or AdminTool override any /etc/defaults/passwd defaults. In other words, defaults set in the /etc/defaults/passwd file are not only applied to those users who do not have corresponding individual settings in their entries in their passwd table.
  • Except for password length, all the /etc/defaults/passwd file defaults are expressed as a number of weeks. (Remember that individual password aging times are expressed as a number of days.)
  • The MAXWEEKS, MINWEEKS, and WARNWEEKS defaults are all counted forward from the date of the user's last password change. (Remember that individual warn values are counted backwards from the maximum date.)
By default, /etc/defaults/passwd files already contain the entries:

MAXWEEKS=
MINWEEKS=
PASSLENGTH=
To implement an entry, simply type the appropriate number after the equal sign. Entries that do not have a number after the equal sign are inactive and have no affect on any user. Thus, to set a MAXWEEKS default of 4, you would change the /etc/defaults/passwd file to read:

MAXWEEKS=4
MINWEEKS=
PASSLENGTH=

Maximum weeks

You can use the MAXWEEKS default in the /etc/defaults/passwd file to set the maximum number of weeks that a user's password is valid. To set a default maximum time period, type the appropriate number of weeks after the equal sign in the MAXWEEKS= line:

MAXWEEKS=N
Where N is a number of weeks. For example, MAXWEEKS=9.

Minimum Weeks

You can use the MINWEEKS default in the /etc/defaults/passwd file to set the minimum nuber of weeks that must pass before a user can change passwords. To set a default minimum time period, type the appropriate number of weeks after the equal sign on the MINWEEKS= line:

MINWEEKS=N
Where N is a number of weeks. For example, MINWEEKS=2.

Warning Weeks

You can add a WARNWEEKS default to the /etc/defaults/passwd file set the number of weeks prior to a password becoming invalid due to aging that user is warned. for example, if you have set the MAXWEEKS default to 9, and you want users to be warned two weeks before their passwords become invalid, you would set the MAXWEEKS default to 7.
There is no point in setting the WARNWEEKS default unless you also set a MAXWEEKS default.
Remember that WARNWEEKS are counted forward from the date of the user's last password change, not backwards from the MAXWEEKS expiration date. Thus, WARNWEEKS must always be less than MAXWEEKS and cannot be equal to or greater than MAXWEEKS .
A WARNWEEKS default will not work unless there is also a MAXWEEKS default.
To set the warning time period, type the appropriate number of weeks after the equal sign on the WARNWEEKS= line.

WARNWEEKS=N
Where N is the number of weeks. For example, WARNWEEKS=1.

Minimum Password Length

By default, the passwd command assumes a minimum length of six characters. You can use the PASSLENGTH default in the /etc/defaults/passwd files to change that by setting the minimum number of characters that a user's password must contain to some other number.
To set the minimum number of characters to something other than six, type the appropriate number of characters after the equal sign in the PASSLENGTH= line:

PASSLENGTH=N
Where N is the number of characters. For example, PASSLENGTH=7.

Password Failure Limits

You can specify a number-of-tries limit or an amount-of-time limit (or both) for a user's attempt to change passwords. These limits are specified by adding arguments when starting the rpc.nispasswdd daemon.
Limiting the number of attempts or setting a time frame provides a limited (but not foolproof) defense against unauthorized persons attempting to change a valid password to one that they discover through trial and error.

Maximum Number of Tries

To set the maximum number of times a user can try to change a password without succeeding, use the -a number argument with rpc.nispasswdd, where number is the number of allowed tries. (You must have superuser privileges on the NIS+ master server to run rpc.nispasswdd.)
For example, to limit users to no more than four attempts (the default is 3), you would type:

station1# rpc.nispasswdd -a 4
In this case, if a user's fourth attempt at logging in is unsuccessful, the message Too many failures - try later is displayed. No further attempts are permitted for that user ID until a specified period of time has passed.

Maximum Login Time Period

To set the maximum amount a time a user can take to successfully change a password, use the -c minutes argument with rpc.nispasswdd, where minutes is the number of minutes a user has to log in. (You must have superuser privileges on the NIS+ master server to run rpc.nispasswdd.)
For example, to specify that users must successfully log in within 2 minutes, you would type:

station1# rpc.nispasswdd -c 2
In this case, if a user is unable to successfully change a password within 2 minutes, the message is displayed at the end of the two-minute period. No further attempts are permitted for that user ID until a specified period of time has passed.
  • © 2010, Oracle Corporation and/or its affiliates
Posted by at No comments:

How to Display the User's Login Status


Before You Begin
To use the logins command, you must become an administrator who is assigned either the User Management or the User Security rights profile. By default, the root role has this authorization. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.2 .
  • Display a user's login status by using the logins command. 
    # logins -x -l username
    –x
    Displays an extended set of login status information.
    –l username
    Displays the login status for the specified user. The variable username is a user's login name. Multiple login names are separated by commas.
    The logins command uses the appropriate password database to obtain a user's login status. The database can be the local /etc/passwd file, or a password database for the naming service. For more information, see the logins (1M) man page.
Example 3-1  Displaying a User's Login Status In the following example, the login status for the user jdoe is displayed.
# logins -x -l jdoe
jdoe       500     staff           10   Jaylee Jaye Doe
/home/jdoe
/bin/bash
PS 010103 10 7 -1
jdoe
Identifies the user's login name.
500
Identifies the user ID (UID).
staff
Identifies the user's primary group.
10
Identifies the group ID (GID).
Jaylee Jaye Doe
Identifies the comment.
/home/jdoe
Identifies the user's home directory.
/bin/bash
Identifies the login shell.
PS 010170 10 7 -1
    Specifies the password aging information:
  • Last date that the password was changed
  • Number of days that are required between changes
  • Number of days before a change is required
  • Warning period

 

++++++++++++++++++++++++++++

 

last

OR

last [UserNameHere]

OR

last [option] [UserNameHere]

Example: Display Linux user last login

To display when a user named ‘vivek’ last logged in to the system, type:
$ last vivek
$ last vivek | less
Sample outputs:

Fig.01: last command in action on my Debian base nas server
Fig.01: last command in action on my Debian base nas server

The output in this example tell us when user vivek last logged in. The output will go back for several months or more as last command searches back through the file /var/log/wtmp and displays a list of all users logged in (and out) since that file was created.

Display a list of recent system use for all users

Simply type the last command:
$ last
OR
$ last | less
Sample outputs taken from my RHEL based server:

root     pts/0        10.1.6.120       Mon Jan 27 06:26   still logged in   
root     pts/0        10.1.6.120       Mon Jan 27 03:37 - 06:26  (02:48)    
root     pts/0        10.1.6.120       Sun Jan 26 02:47 - 09:28  (06:40)    
root     pts/4        10.1.6.120       Sat Jan 25 11:02 - 11:02  (00:00)    
root     pts/0        10.1.6.120       Sat Jan 25 10:15 - 13:12  (02:56)    
root     pts/4        10.1.6.120       Sat Jan 25 06:01 - 06:32  (00:31)    
root     pts/0        10.1.6.120       Sat Jan 25 03:08 - 09:04  (05:55)    
root     pts/4        10.1.6.120       Sat Jan 25 01:06 - 03:18  (02:11)    
root     pts/0        10.1.6.120       Fri Jan 24 23:59 - 02:11  (02:12)    
root     pts/0        10.1.6.120       Fri Jan 24 05:30 - 08:39  (03:08)    
root     pts/0        10.1.6.120       Thu Jan 23 04:22 - 05:41  (01:19)    
....
...
...
root     pts/1        10.1.6.120       Sun Jan  5 11:09 - 14:29  (03:20)    
root     pts/0        10.1.6.120       Sun Jan  5 10:05 - 12:19  (02:14)    
reboot   system boot  2.6.32-431.3.1.e Sun Jan  5 10:02 - 06:52 (21+20:50)  
root     pts/0        10.1.6.120       Sun Jan  5 09:58 - down   (00:00)    
root     pts/0        10.1.6.120       Sun Jan  5 03:33 - 05:45  (02:12)    
root     pts/1        10.1.6.120       Sat Jan  4 15:06 - 17:28  (02:21)    
root     pts/0        10.1.6.120       Sat Jan  4 13:46 - 15:58  (02:11)    
root     pts/0        10.1.6.120       Sat Jan  4 05:05 - 07:16  (02:11)    
root     pts/1        10.1.6.120       Fri Jan  3 14:29 - 15:44  (01:15)    
root     pts/0        10.1.6.120       Fri Jan  3 13:20 - 15:32  (02:11)    
root     pts/0        10.1.6.120       Thu Jan  2 05:19 - 05:32  (00:13)    
root     pts/0        10.1.6.120       Tue Dec 31 13:57 - 16:06  (02:09)    
 
wtmp begins Tue Dec 31 13:57:23 2013

 

Posted by at No comments:

Sunday, 12 July 2020

Linux version check

Using hostnamectl

hostnamectl is most likely the first and last command you need to execute to reveal your RHEL system version: 
$ hostnamectl 
   Static hostname: localhost.localdomain
Transient hostname: status
         Icon name: computer-vm
           Chassis: vm
        Machine ID: d731df2da5f644b3b4806f9531d02c11
           Boot ID: 384b6cf4bcfc4df9b7b48efcad4b6280
    Virtualization: xen
  Operating System: Red Hat Enterprise Linux Server 7.3 (Maipo)
       CPE OS Name: cpe:/o:redhat:enterprise_linux:7.3:GA:server
            Kernel: Linux 3.10.0-514.el7.x86_64
      Architecture: x86-64

Query Release Package

Use rpm command to query Redhat's release package: 
RHEL 7
$ rpm --query redhat-release-server
redhat-release-server-7.3-7.el7.x86_64
RHEL 8
$ rpm --query redhat-release
redhat-release-8.0-0.34.el8.x86_64

Common Platform Enumeration

Check Common Platform Enumeration source file: 
$ cat /etc/system-release-cpe 
cpe:/o:redhat:enterprise_linux:7.3:ga:server

LSB Release

Depending on whether a redhat-lsb package is installed on your system you may also use lsb_release -d command to check Redhat's system version: 
$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
Alternatively install redhat-lsb package with: 
# yum install redhat-lsb
SUBSCRIBE TO NEWSLETTER
Subscribe to Linux Career NEWSLETTER and receive latest Linux news, jobs, career advice and tutorials.

Check Release Files

There are number of release files located in the /etc/ directory. Namely os-release, redhat-release and system-release: 
$ ls /etc/*release
os-release  redhat-release  system-release
Use cat to check the content of each file to reveal your Redhat OS version. Alternatively, use the below for loop for an instant check: 
$ for i in $(ls /etc/*release); do echo ===$i===; cat $i; done
Depending on your RHEL version, the output of the above shell for loop may look different: 
===os-release===
NAME="Red Hat Enterprise Linux Server"
VERSION="7.3 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.3"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.3 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.3:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.3"
===redhat-release===
Red Hat Enterprise Linux Server release 7.3 (Maipo)
===system-release===
Red Hat Enterprise Linux Server release 7.3 (Maipo)

Grub Config

The least reliable way on how to check Redhat's OS version is by looking at Grub configuration. Grub configuration may not produce a definitive answer, but it will provide some hints on how the system booted.

The default locations of grub config files are /boot/grub2/grub.cfg and /etc/grub2.cfg. Use grep command to check for menuentry keyword: 
# grep -w menuentry /boot/grub2/grub.cfg /etc/grub2.cfg
An another alternative is to check the value of the "GRUB Environment Block": 
# grep saved_entry /boot/grub2/grubenv 
saved_entry=Red Hat Enterprise Linux Server (3.10.0-514.el7.x86_64) 7.3 (Maipo)
Posted by at 2 comments:

Saturday, 4 April 2020

hostname change

Method 1 : hostnamectl

To get the current hostname of the system :
# hostnamectl status
   Static hostname: localhost.localdomain
         Icon name: computer
           Chassis: n/a
        Machine ID: 55cc1c57c7f24ed0b0d352648024cea6
           Boot ID: a12ec8e04e6b4534841d14dc8425e38c
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-123.el7.x86_64
      Architecture: x86_64
To set new hostname (geeklab) for the machine :
# hostnamectl set-hostname geeklab    ## static
# hostnamectl set-hostname "Geeks LAB"   ## pretty
Re-login and verify the new hostname :
# hostnamectl
   Static hostname: geekslab
   Pretty hostname: Geeks LAB
         Icon name: computer
           Chassis: n/a
        Machine ID: 55cc1c57c7f24ed0b0d352648024cea6
           Boot ID: a12ec8e04e6b4534841d14dc8425e38c
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-123.el7.x86_64
      Architecture: x86_64

Method 2 : nmcli

To view the current hostname :
# nmcli general hostname
localhost.localdomain
To change the hostname to geeklab :
# nmcli general hostname geeklab
We need to restart the systemd-hostnamed service for the changes to take effect :
# service systemd-hostnamed restart
Re-login and erify the hostname change :
# hostname
geeklab

Method 3 : nmtui

We can also change the hostname using the nmtui tool :
nmtui
Select the option to “set the hostname” and hit enter
change hostname nmtui
Set the hostname
set hostname nmtui
Confirm the hostname change
confirm hostname nmtui
Restart the systemd-hostnamed service for the changes to take effect.
# service systemd-hostnamed restart
Re-login and verify the hostname change.
# hostnamectl
   Static hostname: geeklab
         Icon name: computer
           Chassis: n/a
        Machine ID: 55cc1c57c7f24ed0b0d352648024cea6
           Boot ID: a12ec8e04e6b4534841d14dc8425e38c
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-123.el7.x86_64
      Architecture: x86_64

Method 4 : Edit /etc/hostname

This method requires a reboot of the system. View the current content of the file /etc/hostname.
# cat /etc/hostname
localhost.localdomain
To change the hostname to “geeklab”, replace the content of the /etc/hostname file with “geeklab”
# echo "geeklab" > /etc/hostname
# cat /etc/hostname
geeklab
Restart the system and verify.
# shutdown -r now
# hostname
geeklab
 
=======================================================
This document describes how to edit hostname in Oracle Linux 7.


Note: manually append "HOSTNAME=xxxxx" into file /etc/sysconfig/network and restart system will not work on Oracle Linux 7.


 


Solution


To edit hostname in Oracle Linux 7, use either of following methods:

1. use hostname control utility: hostnamectl
2. use NetworkManager command line tool: nmcli
3. edit /etc/hostname file directly (a reboot afterwards is required)



1. Use hostnamectl which is a command-line client to systemd-hostnamed service



Get current hostname status:


[root@localhost ~]# hostnamectl status
   Static hostname: localhost.localdomain
         Icon name: computer
           Chassis: n/a
        Machine ID: ed264df49f3f42b7b64ca75f763ad117
           Boot ID: 3ec1705218b9499b9619e1bdca7be737
    Virtualization: oracle
  Operating System: Oracle Linux Server 7.1
       CPE OS Name: cpe:/o:oracle:linux:7:1
            Kernel: Linux 3.8.13-55.1.6.el7uek.x86_64
      Architecture: x86_64



Set hostname:


[root@localhost ~]# hostnamectl set-hostname oraclelinux.oracle.com
[root@localhost ~]#



Re-login terminal session:


[root@oraclelinux ~]# hostnamectl status
   Static hostname: oraclelinux.oracle.com
         Icon name: computer
           Chassis: n/a
        Machine ID: ed264df49f3f42b7b64ca75f763ad117
           Boot ID: 3ec1705218b9499b9619e1bdca7be737
    Virtualization: oracle
  Operating System: Oracle Linux Server 7.1
       CPE OS Name: cpe:/o:oracle:linux:7:1
            Kernel: Linux 3.8.13-55.1.6.el7uek.x86_64
      Architecture: x86_64


2. nmcli



Check current hostname:


[root@localhost ~]# nmcli general hostname
localhost.localdomain



Modify hostname and restart ystemd-hostnamed service:


[root@localhost ~]# nmcli general hostname oraclelinux.oracle.com
[root@localhost ~]# systemctl restart systemd-hostnamed



Re-login terminal session:


[root@oraclelinux ~]# hostname
oraclelinux.oracle.com


 


3. Edit /etc/hostname



View current content:


[root@localhost ~]# cat /etc/hostname
localhost.localdomain



Replace file content with new hostname:


[root@localhost ~]# echo "oraclelinux.oracle.com" > /etc/hostname
[root@localhost ~]# cat /etc/hostname
oraclelinux.oracle.com



Restart system and verify:


[root@oraclelinux ~]# hostname
oraclelinux.oracle.com
Posted by at No comments:
Subscribe to: Posts (Atom)