By default the common-password file will contain the following text and it is the min option (min=a1,a2,a3,a4,a5) that will control password complexity.

#%PAM-1.0
password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6
password sufficient /lib/security/$ISA/pam_unix.so use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so

a1 is the password length for passwords that contain one character class. The character classes are lower case characters, upper cases characters, digits and other characters. a2 is the password length for passwords that contain 2 character classes. a3 is used for password phrases. a4 and a5 is the password length required when using 3 or 4 character classes. It should be noted that the first and last character of the password will not count towards the character class count. So the password of ‘Password’ will only have 1 character class, while the password of ‘PassWord’ will have 2.

Note: the values for a1 to a5 must be equal or smaller than the prior value, so min=8,7,7,6,5 will be valid, but min=7,8,9,8,7 will not be. If min=7,8,9,8,7 were used, the error ‘User name or password has an invalid format’ would be generated even if you used a single class password will a length of 7 or more characters.

Sample changes to password complexity

1) To reduce the minimum password length to 6 characters, set min=6,6,6,6,6. As noted above, the values used for a1 to a5 must not be larger than the prior value.

2) To disable the use of one or two class passwords, set min=disabled,disabled,8,8,6. Note that this setting, password of ‘Password1′ would not be valid as the character class count would only be one. A password of ‘pAssw0rd’ would have a class count of 3 and thus be acceptable with a length of 8.

3) To turn off the enforcing of strong passwords, use the enforce option. Valid values for the option are none, users and everyone. So if the common-password file is changed to the below, then a single character password will be allowed regardless of the settings for the min option.

#%PAM-1.0
password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6 enforce=none
password sufficient /lib/security/$ISA/pam_unix.so use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so

Source: vm-help.com

1) At the console of the ESXi host, press ALT-F1 to access the console window.
2) Enter unsupported in the console and then press Enter. You will not see the text you type in.
3) If you typed in unsupported correctly, you will see the Tech Support Mode warning and a password prompt. Enter the password for the root login.
4) You should then see the prompt of ~ #. Edit the file inetd.conf (enter the command vi /etc/inetd.conf).
5) Find the lines that begins with #ssh and remove the #. Then save the file. If you’re new to using vi, then move the cursor down to #ssh line and then press the Insert key. Move the cursor over one space and then hit backspace to delete the #. Then press ESC and type in :wq to save the file and exit vi. If you make a mistake, you can press the ESC key and then type it :q! to quit vi without saving the file. Note: there are two lines for SSH with ESXi 4.0 now – one for regular IP and the other for IPv6. You should the line appropriate to the protocol you’ll use to access your host.
6) Once you’ve closed the vi editor, you can either restart the host or restart the inetd process. To restart inetd run ps | grep inetd to determine the process ID for the inetd process. The output of the command will be something like 1299 1299 busybox inetd, and the process ID is 1299. Then run kill -HUP
(kill -HUP 1299 in this example) and you’ll then be able to access the host via SSH.

Tip – with some applications like WinSCP, the default encryption cipher used is AES. If you change that to Blowfish you will likely see significantly faster transfers.

Changing the port for SSH

To change the port for SSH, edit the file /etc/services and change the SSH port listed in the file. Save the file and repeat step 6 above.

Enable Telnet

The steps are the same as with SSH, but you’ll remove the # from the 2 telnet entries in /etc/inetd.conf. Enabling telnet is not recommended if security is a concern.

You can also download an oem.tgz file which will enable SSH (and FTP). Copy the file to a datastore with the VI client and then to bootbank with the command cp /vmfs/volumes//oem.tgz /bootbank/oem.tgz and then reboot.

Enable SSH access for a non-root account

Use the following process to enable SSH access for a non-root account
1) Access SSH or the console with a root account.
2) Create a new account with the command useradd -M -d/ . This will set the home directory to / instead of requiring a /home directory.
3) Use the command passwd to set the password for your new login.
4) Edit the passwd file with vi /etc/passwd. For the entry for your new account, change the /bin/sh part to /bin/ash. Save the file and exit. See the example for the test1 user below.

root:x:0:0:Administrator:/:/bin/ash
nobody:x:99:99:Nobody:/:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/:/sbin/nologin
dcui:x:100:100:DCUI User:/:/sbin/nologin
daemon:x:2:2:daemon:/:/sbin/nologin
vimuser:x:12:20:vimuser:/sbin:/sbin/nologin
test1:x:500:500:Linux User,,,:/:/bin/ash

You should now be able to connect with SSH using this new account.

Disable SSH access for the root account

If you have created non-root accounts for SSH access you can also disable root access via SSH. Edit the /etc/inetd.conf file using the initial process on this page and add the option -w after the -i option. The line in inetd.conf will appear similar to the below.

ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -w -K60

One you have made the change, save the file and run the kill -HUP command to restart the inetd process. You will now be able to login with a non-root account, but will get access denied if you use a root account. Once you have established a SSH session with your non-root account you can issue the command su – to switch to the root account.

Source : vm-help.com

One of the largest changes between previous versions of Windows and Windows Vista was a move from an INF described OS to componentization.  A component in Windows is one or more binaries, a catalog file, and an XML file that describes everything about how the files should be installed. From associated registry keys and services to what kind security permissions the files should have.  Components are grouped into logical units, and these units are used to build the different Windows editions.

All of the components in the operating system are found in the WinSxS folder – in fact we call this location the component store.  Each component has a unique name that includes the version, language, and processor architecture that it was built for.  The WinSxS folder is the only location that the component is found on the system, all other instances of the files that you see on the system are “projected” by hard linking from the component store.  Let me repeat that last point – there is only one instance (or full data copy) of each version of each file in the OS, and that instance is located in the WinSxS folder.   So looked at from that perspective, the WinSxS folder is really the entirety of the whole OS, referred to as a “flat” in down-level operating systems.  This also accounts for why you will no longer be prompted for media when running operations such as System File Checker (SFC), or when installing additional features and roles.

That explains why the folder starts off big, but not why it gets larger over time – the answer to that question is servicing.   In previous versions of Windows the atomic unit of servicing was the file, in Windows Vista it’s the component.  When we update a particular binary we release a new version of the whole component, and that new version is stored alongside the original one in the component store.  The higher version of the component is projected onto the system, but the older version in the store isn’t touched.  The reason for that is the third part of why the component store gets so large.

Not every component in the component store is applicable, meaning that not every component should be projected onto the system.  For example, on systems where IIS is available but has not been installed, the IIS components are present in the store, but not projected into any location on the system where they might be used.  If you’re familiar with how multi-branch servicing works in previous versions of Windows then it’ll make sense to you that we have a different version of the component for each distribution branch and service pack level, and that all these different versions are also stored in the WinSxS folder, even if they’re not immediately applicable.  So a single Post SP1 GDR package that contains an update to one component will end up installing four versions of that component in the WinSxS folder – double that on a 64 bit operating system for some components.

Now that you know why the store can grow to be so large, your next question is probably to ask why we don’t remove the older versions of the components.  The short answer to that is reliability.  The component store, along with other information on the system, allows us to determine at any given time what the best version of a component to project is.  That means that if you uninstall a security update we can install the next highest version on the system – we no longer have an “out of order uninstall” problem.  It also means that if you decide to install an optional feature, we don’t just choose the RTM version of the component, we’ll look to see what the highest available version on the system is.  As each component on the system changes state that may in turn trigger changes in other components, and because the relationships between all the components are described on the system we can respond to those requirements in ways that we couldn’t in previous OS versions.

The only way to safely reduce the size of the WinSxS folder is to reduce the set of possible actions that the system can take – the easiest way to do that is to remove the packages that installed the components in the first place.  This can be done by uninstalling superseded versions of packages that are on your system.  Service Pack 1 contains a binary called VSP1CLN.EXE, a tool that will make the Service Pack package permanent (not removable) on your system,  and remove the RTM versions of all superseded components.  This can only be done because by making the Service Pack permanent we can guarantee that we won’t ever need the RTM versions. In Service Pack 2 this tool is replaced with COMPCLN

So yes, the WinSXS folder is very large, and it will continue to grow as the OS ages.  I hope that this clears up some of the questions about why that is, and what you can do about it. Note that the Windows servicing structure and the layout of the store is subject to change.

Source : Technet

Linux doesn’t need them, so here is a simple command to get rid of them.

sudo find /home/user -name Thumbs.db -exec rm {} \;

sudo find /begin/here -type d -empty -delete

cd
wget http://launchpadlibrarian.net/59511828/cgroup_patch
chmod +x cgroup_patch
sudo ./cgroup_patch

Now you can either restart your computer or simply run:

sudo /etc/rc.local

Type the following ps command to display all running process:
# ps aux | less

Where,

* -A: select all processes
* a: select all processes on a terminal, including those of other users
* x: select processes without controlling ttys

Task: see every process on the system

# ps -A
# ps -e

Task: See every process except those running as root

# ps -U root -u root -N

Task: See process run by user vivek

# ps -u vivek

Task: top command

The top program provides a dynamic real-time view of a running system.
Type the top at command prompt:
# top

To quit press q, for help press h.

Task: display a tree of processes

pstree shows running processes as a tree. The tree is rooted at either pid or init if pid is omitted. If a user name is specified, all process trees rooted at processes owned by that user are shown.
$ pstree

Task: Print a process tree using ps

# ps -ejH
# ps axjf

Task: Get info about threads

Type the following command:
# ps -eLf
# ps axms

Task: Get security info

Type the following command:
# ps -eo euser,ruser,suser,fuser,f,comm,label
# ps axZ
# ps -eM

Task: Save Process Snapshot to a file

Type the following command:
# top -b -n1 > /tmp/process.log
Or you can email result to yourself:
# top -b -n1 | mail -s ‘Process snapshot’ you@example.com

Task: Lookup process

Use pgrep command. pgrep looks through the currently running processes and lists the process IDs which matches the selection criteria to screen. For example display firefox process id:
$ pgrep firefox

Following command will list the process called sshd which is owned by root user.
$ pgrep -u root sshd

Source : nixCraft

In the CLI type the following

mkdir /media/cdrom
mount /dev/cdrom /media/cdrom
rpm -Uhv /media/cdrom/VMwareTools-3.5.0-{version}.i386.rpm
SuSEconfig
vmware-config-tools.pl ( If you’re getting gcc error’s check this post )
/etc/init.d/network stop
rmmod pcnet32
rmmod vmxnet
depmod -ae
modprobe vmxnet
/etc/init.d/network start

Done