Avocent Cyclades ACS console server password reset or reset unit factory defaults

Avocent Cyclades ACS console server password reset or reset unit factory defaults

The Avocent Cycaldes ACS console servers are great little units that run Linux and even give you full root console access. The root password is “tslinux” by default, but if it has been changed then you can boot the unit into single user mode by supplying the argument “single” to the Linux kernel selection during the boot process (make sure you put a space between the existing Kernel parameters and “single”) which will drop you to a root prompt.

On my unit, this line comes up as right at the start of the boot process:

Linux/PPC load: root=/dev/ram ramdisk=0x0001F000

So you would type ” single” (remember the space!) to give you:

Linux/PPC load: root=/dev/ram ramdisk=0x0001F000 single

Then just hit enter and the unit will boot up into single user mode and give you the root prompt.

At this point, if you want to restore the entire unit to the factory default settings which will erase all of the configuration, then just run “defconf” and then reboot the unit.

If you want to keep the existing configuration intact but just reset the password then you can just use the traditional Linux passwd tool to edit /etc/passwd:

[root@(none) /]# passwd
New password:
Re-enter new password:
Password changed
[root@(none) /]# saveconf
Checking the configuration file list…
Compressing configuration files into /tmp/saving_config.tar.gz … done.
Saving configuration files to flash … done.
[root@(none) /]# reboot
[root@(none) /]# Restarting system.

DNS Configuration in Solaris 10

DNS Configuration in Solaris 10
I like to share configuration of DNS primary and secondary in solaris 10. This implementation was done in a solaris 10 X86.Solaris 10 comes with Bind 9.3 version.

Step 1:

Include the name server in a /etc/resolv.conf file



Here domain name is dev.test.com and there are two name servers defined(192.168.0.1 and 192.168.0.2)

step 2:

Change hosts in nsswitch.conf to point to dns.



Here while querying, it will first look in hosts file then it will go for dns server

I am going to include following host name and ip address in DNS. For this we need to create forward and reverse lookup zones.

Sun10 --> 192.168.0.1
sunclient --> 192.168.0.2
sunclient1 --> 192.168.0.3
sunclient2 --> 192.168.0.4
sunclient3 --> 192.168.0.7

Setting up Primary DNS server

In the below setups i am going to create a zone for domain dev.test.com

Step 1:

Configure /etc/named.conf file. If the file is not available areate new named.conf file




In the above file Secret keys are generated using command "rndc-confgen". We need to include this key in primary and secondary servers named.conf file
for secured zone transfer.

Directory is path where zone db files were kept. Here zone db files were kept in /var/named. We are using type as master since this is a primary server
and the db file name is db.dev and this is kept in path /var/named. Here i created both forward and reverse lookup zone


Step 2:

We need to create domain zone file in /var/named. I am going to create three files for the three zones.




Step 3:

Create named.boot file in /var/named



Thats it we are done

Start dns using either /usr/sbin/named or svcadm enable dns/server




Setting up secondary servers

A Secondary DNS Server is basically just a backup server. I does not hold the master versions of the zone information but rather it holds copies of them. Most sites use Secondary servers in remote locations or to cut down on the load on the Primary server. The Secondary server performs zone transfers at said times making sure it has the newest versions of the zone information.

In order to configure secondary server. we need to make few changes in primary servers zone db file.

Include secondary servers name in db file. I have included secondary server name sun10 in db.dev file, db.192.168.0



Here NS sun10 is secondary server. The same should be included in other zone file db.192.168.0.

create /etc/named.conf file in secodary server



Here i have included type as slave as it is secondary server. we are done now

Because this is a Secondary Server, there is no need to do anything with zone files. BONUS! As long as you have everything setup right on your Primary and your named.conf file is configured properly, everything will work properly.

Each time the Primary site's zone files are modified and the Serial # is incremented, BIND will send out a notify to all Secondaries (any server in the zone file with a IN NS statement) stating a change has been made. BIND on each of these servers will then check it's own zone files to see if it has the same version or not. If the version that the Primary has notified it about is newer then it will perform a zone transfer and obtain the newer version.

If everything is setup properly, you will never need to make any changes to your Secondary server except to upgrade BIND itself. All changes from here on out should be made on the Primary server. The exception is if a new zone is added on the primary, you need to add it to the secondaries also if you want them to be secondary to the new zone.

source :- http://unixtips.hpage.co.in/dns_8462084.html
 

URLS for UNIX

http://unixtips.hpage.co.in/
http://shtnawi.blogspot.in/2011/09/dns.html

DNS Configuration in Solaris 10

DNS Configuration in Solaris 10
I like to share configuration of DNS primary and secondary in solaris 10. This implementation was done in a solaris 10 X86.Solaris 10 comes with Bind 9.3 version.

Step 1:

Include the name server in a /etc/resolv.conf file



Here domain name is dev.test.com and there are two name servers defined(192.168.0.1 and 192.168.0.2)

step 2:

Change hosts in nsswitch.conf to point to dns.



Here while querying, it will first look in hosts file then it will go for dns server

I am going to include following host name and ip address in DNS. For this we need to create forward and reverse lookup zones.

Sun10 --> 192.168.0.1
sunclient --> 192.168.0.2
sunclient1 --> 192.168.0.3
sunclient2 --> 192.168.0.4
sunclient3 --> 192.168.0.7

Setting up Primary DNS server

In the below setups i am going to create a zone for domain dev.test.com

Step 1:

Configure /etc/named.conf file. If the file is not available areate new named.conf file




In the above file Secret keys are generated using command "rndc-confgen". We need to include this key in primary and secondary servers named.conf file
for secured zone transfer.

Directory is path where zone db files were kept. Here zone db files were kept in /var/named. We are using type as master since this is a primary server
and the db file name is db.dev and this is kept in path /var/named. Here i created both forward and reverse lookup zone


Step 2:

We need to create domain zone file in /var/named. I am going to create three files for the three zones.




Step 3:

Create named.boot file in /var/named



Thats it we are done

Start dns using either /usr/sbin/named or svcadm enable dns/server




Setting up secondary servers

A Secondary DNS Server is basically just a backup server. I does not hold the master versions of the zone information but rather it holds copies of them. Most sites use Secondary servers in remote locations or to cut down on the load on the Primary server. The Secondary server performs zone transfers at said times making sure it has the newest versions of the zone information.

In order to configure secondary server. we need to make few changes in primary servers zone db file.

Include secondary servers name in db file. I have included secondary server name sun10 in db.dev file, db.192.168.0



Here NS sun10 is secondary server. The same should be included in other zone file db.192.168.0.

create /etc/named.conf file in secodary server



Here i have included type as slave as it is secondary server. we are done now

Because this is a Secondary Server, there is no need to do anything with zone files. BONUS! As long as you have everything setup right on your Primary and your named.conf file is configured properly, everything will work properly.

Each time the Primary site's zone files are modified and the Serial # is incremented, BIND will send out a notify to all Secondaries (any server in the zone file with a IN NS statement) stating a change has been made. BIND on each of these servers will then check it's own zone files to see if it has the same version or not. If the version that the Primary has notified it about is newer then it will perform a zone transfer and obtain the newer version.

If everything is setup properly, you will never need to make any changes to your Secondary server except to upgrade BIND itself. All changes from here on out should be made on the Primary server. The exception is if a new zone is added on the primary, you need to add it to the secondaries also if you want them to be secondary to the new zone.

Thanks,
Rajeev

Solaris: Which process is associated with a socket connection?

Consider the following real world scenario

[...] one process is waiting for a very long time in a send system call. It is sending on a valid fd but the question we have is that, is there any way to find who is on the other end of that fd? We want to know to which process is that message being sent to. [...]

Here is how I proceed in finding the other end of the socket, and the state of the socket connection with Mozilla's Thunderbird mail client in one end of the socket connection:

1. Get the process id of the application
   

   % prstat
      PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP      
   22385 mandalik  180M   64M sleep   49    0   0:05:15 0.1% thunderbird-bin/5

   
   
2. Run pfiles on the pid - it prints a list of open files including open sockets (pfiles is the Solaris supported equivalent of lsof utility).
   

   % pfiles 22385
   22385:  /usr/lib/thunderbird/thunderbird-bin -UILocale C -contentLocale C
     Current rlimit: 512 file descriptors
     ...
     ...
   
     33: S_IFSOCK mode:0666 dev:280,0 ino:31544 uid:0 gid:0 size:0
         O_RDWR|O_NONBLOCK
           SOCK_STREAM
           SO_SNDBUF(49152),SO_RCVBUF(49640)
           sockname: AF_INET 192.168.1.2  port: 60364
           peername: AF_INET 192.18.39.10  port: 993
           ...
           ...

3. Locate the socket id and the corresponding sockname/port#, peername/port# in the output of pfiles pid (see step #2).
   
   Here my assumption is that I know the socket id I'm interested in. In the above output, 33 is the socket id. One end of the socket is bound to port 60364 on the local host 192.168.1.2; and the other end of the socket is bound to port 993 on the remote host 192.18.39.10.
   
   
4. Run netstat -a | egrep "| (get the port numbers from step 3); and check the state of the socket connection. If you see anything other than ESTABLISHED, it indicates trouble.
   

   % netstat -a | egrep "60364|993"
   solaris-devx-iprb0.60364 mail-sfbay.sun.com.993 48460      0 49640      0 ESTABLISHED

   
   If you want to see the host names in numbers (IP addresses), run netstat with option -n.
   

   %  netstat -an | egrep "60364|993"
   192.168.1.2.60364    192.18.39.10.993     49559      0 49640      0 ESTABLISHED

   
   Now since we know both ends of the socket, we can easily get the state of the socket connection at the other end by running netstat -an | egrep '|.
   
   If the state of the socket connection is CLOSE_WAIT, have a look at the following diagnosis: CPU hog with connections in CLOSE_WAIT.

Finally to answer ... which process is that message being sent to ... part of the original question:

Follow the above steps and find the remote host (or IP) and remote port number. To find the corresponding process id on the remote machine to which the other half of the socket belongs to, do the following:

1. Login as root user on the remote host.
   
2. cd /proc
3. Run pfiles * | egrep "^[0-9]|sockname" > /tmp/pfiles.txt.
   
4. vi /tmp/pfiles.txt and search for the port number. If you scroll few lines up, you can see the process ID, name of the process along with its argument(s).

http://www.feep.net/sendmail/tutorial/intro/MUA-MTA-MDA.html

MUAs, MTAs, and MDAs There are three main parts of the Unix E-mail system: Part What It Does Examples Mail User Agent (MUA) The MUA is the program which the user uses to read and send e-mail. It reads incoming messages that have been delivered to the user's mailbox, and passes outgoing messages to an MTA for sending. elm, pine, mutt Mail Transfer Agent (MTA) The MTA basicly acts as a "mail router". It accepts a message passed to it by either an MUA or another MTA, decides based upon the message header which delivery method it should use, and then passes the message to the appropriate MDA for that delivery method. sendmail, postfix, qmail Mail Delivery Agent (MDA) The MDA accepts a piece of mail from an MTA and performs the actual delivery. mail.local, procmail The MTA is the most important one of these. It is responsible for doing all the "intelligent" work of e-mail transfer. While it does not actually perform any of the delivery itself, it is the part which tells the other parts how to interact and what to do. In a sense, the MTA is the glue which holds the whole process together. To illustrate how the three parts of the email system work together, here's a very general example. This is what happens when the user jsmith@host1.uiuc.edu sends e-mail to johndoe@host2.uiuc.edu: jsmith's MUA (pine, elm, etc) on host1.uiuc.edu passes the message to the MTA (sendmail) on the local host. The MTA (sendmail) notices that the message is addressed to a user at host2.uiuc.edu. Since it is configured to know that it can reach host2.uiuc.edu via SMTP, it passes the message to the SMTP MDA (the SMTP MDA is actually builtin to sendmail, but all other MDAs are external programs). The SMTP MDA connects to the MTA on host2.uiuc.edu (sendmail) and sends it the message. The MTA on host2.uiuc.edu (sendmail) notices that the message is addressed to a user on the local host, so it passes the message to the local MDA. The local MDA saves the message in user johndoe's mailbox. The next time johndoe logs in to host2.uiuc.edu and runs his MUA, the message is there waiting for him to read. As you can see, none of this would be possible without the MTA!

Breaking RCS locks.

Breaking RCS locks. So you want to edit some awesome file, only to see this when you check it out: co -l /mnt/yp/netgroup /mnt/yp/RCS/netgroup,v --> /mnt/yp/netgroup co: /mnt/yp/RCS/netgroup,v: Revision 1.1008 is already locked by u0064824. Blood and ashes! Here's how to break the lock so the world can move forward. First move the file to a backup location: mv /mnt/yp/netgroup /mnt/yp/netgroup-lockedByu0064824-Sep272002 Then break the lock rcs -u /mnt/yp/netgroup RCS file: RCS/netgroup,v Revision 1.1008 is already locked by u0064824. Do you want to break the lock? [ny](n): y State the reason for breaking the lock: (terminate with single '.' or end of file) >> Testing lock breaking -SH. >> . 1.1008 unlocked done Now you can check out the file and using diff (or vimdiff) you can see what changes the previous user made so you can hopefully merge in any changes they might have made. co -l /mnt/yp/netgroup diff /mnt/yp/netgroup /mnt/yp/netgroup-lockedByu0064824-Sep272002 Then edit away! When you're done we check the file in such that it stays in place and isn't magicly whisked away in the RCS repository: ci -u /mnt/yp/netgroup