root@jumpy # cat /etc/default/telnetd BANNER="\\n\\nBIKASH KUMAR\\n\\n" root@jumpy # telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. it will display ............ BIKASH KUMAR
Wednesday, March 13, 2013
How to Create Banner/Login Messages in Solaris.
Monday, March 11, 2013
Step by step configuration of the XSCF console for the Sun SPARC M3000 server
XSCF (eXtended System Control Facility is used to control, monitor,
operate, and service SPARC Enterprise series servers and domains. You
can power on/off the server (domain) via the XSCF interface. As long as
the server is plugged into a power source the XSCF console will always
be online even though the domain (server) is off. For those who are
familiar with Windows servers, the XSCF is similar to the DRAC interface
for Dell servers or HP Insight Manager.
When you are connected to the XSCF console, you will be prompted for a login ID. The default ID is “default” and there is no password. With this ID you will need to create a new administrative ID. You also need to be standing close to the server for this process as you will be prompted to change the panel mode switch. If you do not create a new logon ID whenever you connect to the console or when the console session times out, you will be prompted to change the panel mode switch.
Configure DSCP with an IP address using the setdscp command.
First generate the web server private key. Remember the passphrase you will need it in the next step.
Create the self-signed web server certificate by speficying the DN.
When you are connected to the XSCF console, you will be prompted for a login ID. The default ID is “default” and there is no password. With this ID you will need to create a new administrative ID. You also need to be standing close to the server for this process as you will be prompted to change the panel mode switch. If you do not create a new logon ID whenever you connect to the console or when the console session times out, you will be prompted to change the panel mode switch.
login: defaultCheck the version of XSCF.
Change the panel mode switch to Locked and press return…
Leave it in that position for at least 5 seconds. Change the panel mode switch
to Service, and press return…
XSCF> version -c xcpCreate a user andrew
XSCF#0 (Active )
XCP0 (Current): 1090
XCP1 (Reserve): 1090
XSCF> adduser andrewChange the password for andrew
XSCF> password
password: Permission denied
XSCF> password andrewGrant andrew the following privileges, useradm, platadm, aplatop.
New XSCF password:
Retype new XSCF password:
XSCF> setprivileges andrew useradm platadm platopHere is a list of all available privileges.
domainop@nXSCF firmware has two networks for internal communication. The Domain to Service Processor Communications Protocol (DSCP) network provides an internal communication link between the Service Processor and the Solaris domains. The Inter-SCF Network (ISN) provides an internal communication link between the two Service Processors in a high-end server.
• Can refer to the status of any hardware mounted in a domain_n.
• Can refer to the status of any part of a domain_n.
• Can refer to the information of all system boards mounted.
domainmgr@n
• Can power on, power off, and reboot a domain_n.
• Can refer to the status of any hardware mounted in a domain_n.
• Can refer to the status of any part of a domain_n.
• Can refer to the information of all system boards mounted.
platop
• Can refer to the status of any part of the entire server but cannot change it.
platadm
• Control of the entire system
• Can operate all hardware in the system.
• Can configure all XSCF settings except the useradm and auditadm privilege settings.
• Can add and delete hardware in a domain.
• Can do the power operation of a domain.
• Can refer to the status of any part of the entire server.
useradm
• Can create, delete, invalidate, and validate user accounts.
• Can change user passwords and password profiles.
• Can change user privileges.
auditop
• Can refer to the XSCF access monitoring status and monitoring methods.
auditadm
• Can monitor and control XSCF access.
• Can delete an XSCF access monitoring method.
fieldeng
• Allows field engineers to perform the maintenance tasks or change the server configuration.
None
• When the local privilege for a user is set to none, that user has no privileges, even if the privileges
for that user are defined in LDAP.
• Setting a user’s privilege to none prevents the user’s privileges from being looked up in LDAP.
Configure DSCP with an IP address using the setdscp command.
XSCF> setdscpConfigure the XSCF interface with an IP address, this will be the adress you connect to via telnet to manage the console.
DSCP network [0.0.0.0 ] > 10.1.1.0
DSCP netmask [255.0.0.0 ] > 255.255.255.0
XSCF address [10.1.1.1 ] >
Domain #00 address [10.1.1.2 ] >
Commit these changes to the database? [y|n] : y
XSCF> setnetwork xscf#0-lan#0 -m 255.255.0.0. 162.10.10.11Enable the XSCF interface you just configured with an IP address of 162.10.10.11
XSCF> setnetwork -c up lan#0Confiure the default route
XSCF> setroute -c add -n 0.0.0.0 -g 162.10.10.1 xscf#0-lan#1Configure the hostname.
XSCF> showroute -a
Destination Gateway Netmask Flags Interface
1622.10.0.0 * 255.255.0.0 U xscf#0-lan#0
XSCF> sethostname xscf#0 parisConfigure the domain name.
XSCF> sethostname -d parishilton.comYou must apply the network configurations with the applynetwork command.
XSCF> applynetworkNow reboot XSCF for the configuration to take effect.
The following network settings will be applied:
xscf#0 hostname :paris
DNS domain name :parishilton.com
interface : xscf#0-lan#0
status :up
IP address :162.10.10.11
netmask :255.255.0.0
route :
interface : xscf#0-lan#1
status :down
IP address :
netmask :
route :
Continue? [y|n] :yes
Please reset the XSCF by rebootxscf to apply the network settings.
Please confirm that the settings have been applied by executing
showhostname, shownetwork, showroute and shownameserver after rebooting
the XSCF.
XSCF> rebootxscfAfter the reboot check the network settings.
XSCF> shownetwork -aEnable ssh, it will require a reboot.
xscf#0-lan#0
Link encap:Ethernet HWaddr 00:0B:5D:E3:39:B4
inet addr:162.10.10.11 Bcast:162.10.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13160 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1943545 (1.8 MiB) TX bytes:210 (210.0 B)
Base address:0xe000
xscf#0-lan#1
Link encap:Ethernet HWaddr 00:0B:5D:E3:39:B5
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0xc000
XSCF> setssh -c enableEnable telnet. You probably do not need telnet if ssh is enabled.
Continue? [y|n] :y
Please reset the XSCF by rebootxscf to apply the ssh settings.
XSCF> settelnet -c enableIt is much easier to configure and manage XSCF via https as you do not have to remember all the commands. I will show you how to enable https by creating a Web Server Certificate by constructing the self CA.
XSCF> showtelnet
Telnet status: enabled
First generate the web server private key. Remember the passphrase you will need it in the next step.
XSCF> sethttps -c genserverkey
Enter passphrase:
Verifying – Enter passphrase:
XSCF> sethttps -c selfsign CA Ontario Toronto CupidPost Technology Center andrew_lin@email.comNow enable https.
CA key and CA cert already exist. Do you still wish to update? [y|n] :y
Enter passphrase:
Verifying – Enter passphrase:
XSCF> sethttps -c enableReboot with the rebootxscf command,
Continue? [y|n] :y
Please reset the XSCF by rebootxscf to apply the https settings.
XSCF> rebootxscfAfter the reboot you can connect to the XSCF console by telnet, ssh or https.
The XSCF will be reset. Continue? [y|n] :y
Tuesday, March 5, 2013
How to delete the bash history
To delete the history of your older sessions:
cd
rm .bash_history
To delete the history of your current session:
history -c
cd
rm .bash_history
To delete the history of your current session:
history -c
Recently we went thru re-IPing all of our servers and storage
arrays in our office. For the most part everything went fine with the
exception of a Solaris 10 U3 server I was running iSCSI on.
After I got thru the steps of changing the server's IP address, gateway and DNS entries I rebooted the server. Upon reboot, I noticed a flurry of non-stop error messages at the server's console:
Sep 30 18:37:37 longhorn iscsi: [ID 286457 kern.notice] NOTICE: iscsi connection(8) unable to connect to target SENDTARGETS_DISCOVERY (errno:128)Sep 30 18:37:37 longhorn iscsi: [ID 114404 kern.notice] NOTICE: iscsi discovery failure - SendTargets (0xx.0xx.0xx.0xx)
As a result of this, I was never able to get a login prompt either at the console or via telnet even though I could succesfuly ping the server's new IP address. What the message above indicates is that the initiator issues a SendTargets and waits for the Target to respond with its Targets. To my surprise there's NO timeout and the initiator will try this process indefinately. In fact, just for kicks, I left it trying for an hour and 45'.
That also means that you will be locked out of the server, as attempting to boot into single user mode results in the exact same behavior.
To get around this problem you have 2 options even though option #2, for some, may not be an option.
Option 1
--------
a) Boot from a Solaris cdrom
b) mount /dev/dsk/c#t#d#s0 /a
c) cd /a/etc/iscsi
d) Remove or rename *.dbc and *.dbp files (iscsi not configured any longer)
e) Reboot the server
f) Use iscsiadm and configure the Solaris server with Static discovery (static-config) so you don't get into this situation again
Option 2
---------
a) Change back to the old Target IP address
b) That will enable you to reboot the server
c) Reconfigure the server to use static-config by specifying the target-name, new Target-ip-address and port-number
d) Change the Target IP address to the new one
I followed Option #1 because #2 was not really not an option for us. So the morale of the story is that you may want to consider static-discovery on Solaris with iSCSI.
After I got thru the steps of changing the server's IP address, gateway and DNS entries I rebooted the server. Upon reboot, I noticed a flurry of non-stop error messages at the server's console:
Sep 30 18:37:37 longhorn iscsi: [ID 286457 kern.notice] NOTICE: iscsi connection(8) unable to connect to target SENDTARGETS_DISCOVERY (errno:128)Sep 30 18:37:37 longhorn iscsi: [ID 114404 kern.notice] NOTICE: iscsi discovery failure - SendTargets (0xx.0xx.0xx.0xx)
As a result of this, I was never able to get a login prompt either at the console or via telnet even though I could succesfuly ping the server's new IP address. What the message above indicates is that the initiator issues a SendTargets and waits for the Target to respond with its Targets. To my surprise there's NO timeout and the initiator will try this process indefinately. In fact, just for kicks, I left it trying for an hour and 45'.
That also means that you will be locked out of the server, as attempting to boot into single user mode results in the exact same behavior.
To get around this problem you have 2 options even though option #2, for some, may not be an option.
Option 1
--------
a) Boot from a Solaris cdrom
b) mount /dev/dsk/c#t#d#s0 /a
c) cd /a/etc/iscsi
d) Remove or rename *.dbc and *.dbp files (iscsi not configured any longer)
e) Reboot the server
f) Use iscsiadm and configure the Solaris server with Static discovery (static-config) so you don't get into this situation again
Option 2
---------
a) Change back to the old Target IP address
b) That will enable you to reboot the server
c) Reconfigure the server to use static-config by specifying the target-name, new Target-ip-address and port-number
d) Change the Target IP address to the new one
I followed Option #1 because #2 was not really not an option for us. So the morale of the story is that you may want to consider static-discovery on Solaris with iSCSI.
Sensors on SPARC Enterprise T5440
Sensors on SPARC Enterprise T5440
Server
TABLE: Temperature Sensors
Path Description
/SYS/MB/T_* Motherboard
/SYS/MB/DVRM_*/T_* Motherboard Voltage Regulator
/SYS/MB/CPUn/T_* CPU Board (0-3)
/SYS/MB/CPUn/DVRM_*/T_* CPU Board (0-3) Voltage Regulator
/SYS/MB/MEMn/DVRM_*/T_* Memory Board (0-3) Voltage Regulator
TABLE: Voltage Sensors
Path Description
/SYS/MB/V_* Motherboard
/SYS/MB/DVRM_*/V_* Motherboard Voltage Regulator
/SYS/MB/CPUn/V_* CPU Board (0-3)
/SYS/MB/CPUn/DVRM_*/V_* CPU Board (0-3) Voltage Regulator
/SYS/MB/MEMn/DVRM_*/V_* Memory Board (0-3) Voltage Regulator
/SYS/MB/SP/V_* Service Processor
TABLE: Load (Current) Sensors
Path Description
/SYS/PSn/I_* Power Supply (0-3)
/SYS/MB/CPUn/DVRM_*/I_* CPU Board (0-3) Voltage Regulator
TABLE: Power Supply Status Sensors
Path Description
/SYS/PSn/*_POK Power Supply (0-3) Power OK
/SYS/PSn/*_FAULT Power Supply (0-3) Fault
==============================================================
Indicators on the SPARC Enterprise
T5440 Server
TABLE: Indicators on the Server
Name Path Description
System Level Indicators
LOCATE /SYS/LOCATE Locate indicator
ACT /SYS/ACT System Power
Activity indicator
SERVICE /SYS/SERVICE Service indicator
Individual Component Indicators
PS_FAULT /SYS/PS_FAULT Power Supply Fault
indicator
TEMP_FAULT /SYS/TEMP_FAULT Temperature Fault
indicator
FAN_FAULT /SYS/FAN_FAULT Fan Fault indicator
HDDn/FAULT /SYS/HDDn/FAULT Hard Disk (0-3) Fault
indicator
HDDn/OK2RM /SYS/HDDn/OK2RM Hard Disk (0-3) Okay
to Remove indicator
FTn/FAULT /SYS/MB/FTn/FAULT Fan Module Fault
indicator
CPUn/FAULT /SYS/MB/CPUn/FAULT CPU Board Fault
indicator
MEMn/FAULT /SYS/MB/MEMn/FAULT Memory Board Fault
indicator
/CPUn/CMPn/BRn/CHn/D0 /SYS/MB/CPUn/CMPn/BRn/CHn/D0 CPU Board DIMM
Fault indicator
/MEMn/CMPn/BRn/CHn/Dn /SYS/MB/MEMn/CMPn/BRn/CHn/Dn Memory Board
DIMM Fault
indicato
Server
TABLE: Temperature Sensors
Path Description
/SYS/MB/T_* Motherboard
/SYS/MB/DVRM_*/T_* Motherboard Voltage Regulator
/SYS/MB/CPUn/T_* CPU Board (0-3)
/SYS/MB/CPUn/DVRM_*/T_* CPU Board (0-3) Voltage Regulator
/SYS/MB/MEMn/DVRM_*/T_* Memory Board (0-3) Voltage Regulator
TABLE: Voltage Sensors
Path Description
/SYS/MB/V_* Motherboard
/SYS/MB/DVRM_*/V_* Motherboard Voltage Regulator
/SYS/MB/CPUn/V_* CPU Board (0-3)
/SYS/MB/CPUn/DVRM_*/V_* CPU Board (0-3) Voltage Regulator
/SYS/MB/MEMn/DVRM_*/V_* Memory Board (0-3) Voltage Regulator
/SYS/MB/SP/V_* Service Processor
TABLE: Load (Current) Sensors
Path Description
/SYS/PSn/I_* Power Supply (0-3)
/SYS/MB/CPUn/DVRM_*/I_* CPU Board (0-3) Voltage Regulator
TABLE: Power Supply Status Sensors
Path Description
/SYS/PSn/*_POK Power Supply (0-3) Power OK
/SYS/PSn/*_FAULT Power Supply (0-3) Fault
==============================================================
Indicators on the SPARC Enterprise
T5440 Server
TABLE: Indicators on the Server
Name Path Description
System Level Indicators
LOCATE /SYS/LOCATE Locate indicator
ACT /SYS/ACT System Power
Activity indicator
SERVICE /SYS/SERVICE Service indicator
Individual Component Indicators
PS_FAULT /SYS/PS_FAULT Power Supply Fault
indicator
TEMP_FAULT /SYS/TEMP_FAULT Temperature Fault
indicator
FAN_FAULT /SYS/FAN_FAULT Fan Fault indicator
HDDn/FAULT /SYS/HDDn/FAULT Hard Disk (0-3) Fault
indicator
HDDn/OK2RM /SYS/HDDn/OK2RM Hard Disk (0-3) Okay
to Remove indicator
FTn/FAULT /SYS/MB/FTn/FAULT Fan Module Fault
indicator
CPUn/FAULT /SYS/MB/CPUn/FAULT CPU Board Fault
indicator
MEMn/FAULT /SYS/MB/MEMn/FAULT Memory Board Fault
indicator
/CPUn/CMPn/BRn/CHn/D0 /SYS/MB/CPUn/CMPn/BRn/CHn/D0 CPU Board DIMM
Fault indicator
/MEMn/CMPn/BRn/CHn/Dn /SYS/MB/MEMn/CMPn/BRn/CHn/Dn Memory Board
DIMM Fault
indicato
Solaris 10 iSCSI configured with Dynamic Discovery
Recently we went thru re-IPing all of our servers and storage
arrays in our office. For the most part everything went fine with the
exception of a Solaris 10 U3 server I was running iSCSI on.
After I got thru the steps of changing the server's IP address, gateway and DNS entries I rebooted the server. Upon reboot, I noticed a flurry of non-stop error messages at the server's console:
Sep 30 18:37:37 longhorn iscsi: [ID 286457 kern.notice] NOTICE: iscsi connection(8) unable to connect to target SENDTARGETS_DISCOVERY (errno:128)Sep 30 18:37:37 longhorn iscsi: [ID 114404 kern.notice] NOTICE: iscsi discovery failure - SendTargets (0xx.0xx.0xx.0xx)
As a result of this, I was never able to get a login prompt either at the console or via telnet even though I could succesfuly ping the server's new IP address. What the message above indicates is that the initiator issues a SendTargets and waits for the Target to respond with its Targets. To my surprise there's NO timeout and the initiator will try this process indefinately. In fact, just for kicks, I left it trying for an hour and 45'.
That also means that you will be locked out of the server, as attempting to boot into single user mode results in the exact same behavior.
To get around this problem you have 2 options even though option #2, for some, may not be an option.
Option 1
--------
a) Boot from a Solaris cdrom
b) mount /dev/dsk/c#t#d#s0 /a
c) cd /a/etc/iscsi
d) Remove or rename *.dbc and *.dbp files (iscsi not configured any longer)
e) Reboot the server
f) Use iscsiadm and configure the Solaris server with Static discovery (static-config) so you don't get into this situation again
Option 2
---------
a) Change back to the old Target IP address
b) That will enable you to reboot the server
c) Reconfigure the server to use static-config by specifying the target-name, new Target-ip-address and port-number
d) Change the Target IP address to the new one
I followed Option #1 because #2 was not really not an option for us. So the morale of the story is that you may want to consider static-discovery on Solaris with iSCSI.
After I got thru the steps of changing the server's IP address, gateway and DNS entries I rebooted the server. Upon reboot, I noticed a flurry of non-stop error messages at the server's console:
Sep 30 18:37:37 longhorn iscsi: [ID 286457 kern.notice] NOTICE: iscsi connection(8) unable to connect to target SENDTARGETS_DISCOVERY (errno:128)Sep 30 18:37:37 longhorn iscsi: [ID 114404 kern.notice] NOTICE: iscsi discovery failure - SendTargets (0xx.0xx.0xx.0xx)
As a result of this, I was never able to get a login prompt either at the console or via telnet even though I could succesfuly ping the server's new IP address. What the message above indicates is that the initiator issues a SendTargets and waits for the Target to respond with its Targets. To my surprise there's NO timeout and the initiator will try this process indefinately. In fact, just for kicks, I left it trying for an hour and 45'.
That also means that you will be locked out of the server, as attempting to boot into single user mode results in the exact same behavior.
To get around this problem you have 2 options even though option #2, for some, may not be an option.
Option 1
--------
a) Boot from a Solaris cdrom
b) mount /dev/dsk/c#t#d#s0 /a
c) cd /a/etc/iscsi
d) Remove or rename *.dbc and *.dbp files (iscsi not configured any longer)
e) Reboot the server
f) Use iscsiadm and configure the Solaris server with Static discovery (static-config) so you don't get into this situation again
Option 2
---------
a) Change back to the old Target IP address
b) That will enable you to reboot the server
c) Reconfigure the server to use static-config by specifying the target-name, new Target-ip-address and port-number
d) Change the Target IP address to the new one
I followed Option #1 because #2 was not really not an option for us. So the morale of the story is that you may want to consider static-discovery on Solaris with iSCSI.
Subscribe to:
Posts (Atom)