NDISwrapper Setup Information (SUSE Linux 10.1, 10.2, 10.3, and SLED/SLES)

Pre-Flight Checklist

In order to use this guide, you will need to prepare the following:

1. An installed copy of SuSE Linux, 10.1 or greater, or a copy of SUSE Linux Enterprise Desktop/Server 10. This guide will not work for SUSE Linux 10.0 – please see the 32-bit guide or the 64-bit guide for SUSE Linux 10.0.
2. A wireless network card.
3. An existing internet connection of some kind.
4. Your OWN bag of Skittles®, since this bag is mine

Installing via Repositories

f the SUSE 10.x box is connected to the internet already, and you’re just trying to get WIFI working, this is the section for you. Once you have completed this section, you will be ready to install the Windows XP drivers and get your internet working. Let’s begin.

1. Start YaST.
2. Left-click once on the “Installation Sources” or “Software Repositories” button. After a minute, a list of repositories will appear.
3. Left-click once on the “Add” button at the bottom left of the screen.
4. Left-click once on the “Specify URL…” button at the bottom of the list.
5. Left-click once on the “Next” button at the bottom right corner of the screen.
6. Insert one of the following URLs into the box, depending on what distribution you run.

   NOTE: Any and all packages for OpenSUSE 10.3 are now handled by Andrea F., who is part of the Packman repository. Please update your links.

   SLES\SLED 10: http://download.opensuse.org/repositories/home:/andrewd18/SLE_10/
   SUSE Linux 10.1: http://download.opensuse.org/repositories/home:/andrewd18/SUSE_Linux_10.1/
   OpenSUSE 10.2: http://download.opensuse.org/repositories/home:/andrewd18/openSUSE_10.2/
   OpenSUSE 10.3 (USA Mirror): http://packman.unixheads.com/suse/10.3/
   OpenSUSE 10.3 (Germany Mirror): http://packman.iu-bremen.de/suse/10.3/

7. Left-click once on the “Next” button at the bottom right corner of the screen. You will be returned to the list of repositories.
8. Left-click once on the “Finish” button at the bottom right corner of the screen. You will be returned to the main YaST screen.
9. Left-click once on the “Install/Remove Software” or “Software Management” button. After a minute or three, software installation page will appear.
10. Type kernel into the search box and left-click once on the “Search” button.
11. Find the kernel package that is installed (it will have a checkmark or a lock next to it). Write down the name of the kernel, for example, “kernel-default” or “kernel-bigsmp”.
12. Type “ndis” into the search box and left-click once on the “Search” button.
13. Right-click once on the ndiswrapper package. A menu will appear.
14. Left-click once on either “Install” or “Update”.
15. Right-click once on the ndiswrapper-kmp* package that corresponds with the kernel you wrote down above. For example, if you had the kernel-default package, you would right-click on the ndiswrapper-kmp-default package.
16. Left-click once on either “Install” or “Update”.
17. Right-click once on the ndisgtk package. A menu will appear.
18. Left-click once on either “Install” or “Update”.
19. Left-click once on the “Accept” button in the bottom right corner of the screen. The software will be installed.
20. Exit YaST.

Readying the Drivers

Now that all the software we need is installed, we need to bring the drivers our hardware needs to the SUSE machine.

1. Visit the ndiswrapper Ndiswrapper WIKI: Card Listing to see if a certain Windows XP driver is known to work for your WIFI card.
2. Download either the Windows XP driver listed on the WIKI, or the latest Windows XP driver off your manufacturer’s website.
3. Place the drivers on the Desktop of your SUSE Linux machine, unzipping them if necessary.

Continue to the Installing Drivers with NDISGTK section.

Installing Drivers with NDISGTK

Now that all the software we need is installed, we can give ndiswrapper the Windows XP drivers.

1. Start NDISGTK. It should be located in your menu at Applications -> System -> More Programs -> NDISGTK
2. Click “Install New Driver”.
3. Point NDISGTK to the .inf file for your WIFI card.
4. Click the “Install” button.
5. Verify that NDISGTK shows your driver is installed and that the hardware is present.
6. Click “Configure Network” and continue to the YaST Configuration section.

YaST Configuration

Now you have arrived at the best part, the part where you actually get the wireless card to connect to your router so you can surf the internet! I highly suggest that you configure your WIFI card with YaST.

1. In NDISGTK, left-click once on the “Configure Network” button. YaST’s network module will appear. (This screen can also be accessed through YaST -> Network Devices -> Network Card)
2. Choose either “Traditional Method with IFUP” or “User Controlled with NetworkManager”. Most users will want NetworkManager. SUSE 10.1 users should be advised that NetworkManager is broken on their distribution.

If your card is listed, continue with step 3. If your card is not listed, skip to step 9.

3. Left-click once on your card’s listing.
4. Left-click once on the “Edit” button.
5. Left-click once on the “Advanced” button.
6. Left-click once on the “Hardware Details” menu item.
7. Change the Module Name field from whatever it currently is to ndiswrapper.
8. Skip to step 13.
9. Left-click once on the “Add” button.
10. Left-click once on the “Device Type” pull-down menu and then left-click once on “Wireless”.
11. Enter ndiswrapper into the Module Name field.
12. Left-click once on the PCMCIA or USB button if appropriate.
13. Left-click once on the “OK” button.
14. Left-click once on the “Next” button.
15. Left-click once on the “Operating Mode” pull-down menu and then left-click on either Ad-Hoc, Managed, or Master. Most users will want Managed mode.
16. Enter your router’s ESSID into the “ESSID” field.
17. Left-click once on the “Authentication Mode” pull-down menu and choose either Open, Shared Key, WPA-EAP, or WPA-PSK.
18. Enter your encryption key in the “Encryption Key” field if appropriate.
19. WPA Users: Left-click once on the “Next” button.
20. WPA Users: Enter your encryption/login settings as appropriate.
21. Left-click once on the “Next” button.
22. Left-click once on the “Finish” button.
23. Exit YaST.
24. Exit NDISGTK

If everything worked properly, you should be connected to your network and the internet. Congratulations.

The Original link is here:

http://www.andrewd18.com/ndiswrapper/ndiswrapperinfo-gui.php#Readying

How to access Windows Fat32 partition in Suse 10.3?

ntroduction: Continuing Windows users who install Linux like to maintain a Fat32 partition for data storage and swapping between Windows and Linux. Often they get “Permission denied” or similar messages when they try to write to the Fat partitions. This Tutorial shows how you set the user and group IDs in the file system table located at /etc/fstab to allow broad writeable access. The easy way is just to edit the fstab entries entries but if you’re from Windows Land you will be slaves to the GUI for a while. I do include fstab entries for advanced users who might browse here for reference.Scene Setting: The screenshot to left, Pic 1, shows my filesystem viewed in Yast’s Expert Partitioner, located at Yast –> System –> Partitioner. Yours will of course be different.

There are eleven partitions in this example on my primary drive, sda, and the Fat32 partition is highlighted in blue, partition sda3. We’re only concerned here with the Fat32 partition.

Mount Point: The files on the Fat32 partition will appear in a directory/folder of your choice once sda3 is mounted. For illustration I choose “fat32″ in the directory /mnt; this directory is conventionally used in Suse for locating mounts although there’s no compulsion to use it. So for illustration the mount point is /mnt/fat32.

Mounting using Yast: In Yast –> System –> Partitioner you highlight the Fat32 partition in Pic 1 and click “Edit”. The screen in Pic 2 opens up and there you insert into the panel for “Mount Point” the path to the directory of your choice; e.g. /mnt/fat32.

Then Click “Fstab Options” in Pic 2 to set ownership and other details. The screen in Pic 3 will open up. Activate the selection “Device Name”. If the line users,gid=users,umask=0002,utf8 is not in the slot for “Arbitrary option values” then type it in. This line gives ownership to root and read/write access to all users. These permissions are meaningless in Windows and do not carry across when viewed there. In Windows all files belong to all users.

From this point you click the appropriate “OK”, “Next” and “Apply” buttons to make it happen.

Permissions on the mount point: The mount point, /mnt/fat32, needs to have ownership=root and group=users. In openSUSE 10.3 that happens automagically but it doesn’t happen that way in openSUSE 10.2 or Suse 10.0, 10.1. You must make the necessary changes to the mount point (folder/directory) when the partition is NOT mounted.

Here are the extra steps needed in Suse 10.0, 10.1 and openSUSE 10.3.

• • Open a terminal and assume root privileges with command: su
• • Unmount the partition with command: umount /dev/sda3
• • Change ownership with command: chown -R root:users /mnt/fat32
• • Change permissions with command: chmod 775 /mnt/fat32

Just for completeness, you could do the last three steps in a GUI using Konqueror or Nautilus. First unmount the partition. Then Navigate to the folder /mnt/fat32 and change the ownership and permissions as shown for Konqueror on the left in Pic 4.

Here is the entry in fstab for the mount:

/dev/sda3 /mnt/fat32 vfat users,gid=users,umask=0002,utf8=true 0 0

Bug in Yast Partitioner in openSUSE 10.3: Sometimes in 10.3 the line in fstab for the mount lists the device by device ID rather than by device path as emphasised in red in Pic 3. Why? It is because even though you choose “Device name” in Pic 3, you get “Device ID” transferring through to fstab. That’s a bug in Yast Partitioner but only in 10.3. You can fix that by editing the entry in fstab and changing it to look like the line directly above. You can edit fstab directly with this command in a terminal:

For KDE use kdesu kwrite /etc/fstab

For Gnome use gnomesu gedit /etc/fstab

I will remove this bug work-around when and if it’s fixed. Please let me know if you discover it’s fixed before I do.

But I want Privacy From Others: In this case you make the mount point in the territory of the chosen user, say at /home/michael/fat32. It’s a standard folder with no special permissions, owned by “michael” with default permissions drwxr-xr-x. Do that first. You can mount the partition in Yast using the new mount point (/home/michael/fat32) instead of the one shown in Pic 2 and these “Arbitrary options” instead of the ones shown in Pic 3: uid=michael,gid=users,utf8=true.

Now the Fat32 partition will be writeable by Michael and readable by all users. If you want absolute privacy you can make a directory within fat32 that is “forbidden” to all users but Michael. Note that you cannot make the directory fat32 forbidden to other users, only directories under directory fat32. Here is the entry in fstab for the fat32 partition under these more restricted circumstances:

/dev/sda3 /home/michael/fat32 vfat uid=michael,gid=users,utf8=true 0 0

That’s all folks. Hope it helps.

Why can’t we create a folder by name CON? February 21, 2008

Posted by raghupathy in Windows.
add a comment

I’ve been asked this question many a times: Why can’t we create a folder by name CON? Although it seems a wonder or magic that we can’t create a folder by that name, in reality, it is not so. It has a definite reason, and in fact, a folder can be created using that reserved name.Gone are the days when computers had only CUI OS, that is, Character User Interface Operating Systems, like MS-DOS. When I joined my first computer course nine years ago, Windows 95 was ruling. You could see Windows 98 here and there. We were in 8th standard, and working on a computer was like a dream coming true. Microsoft’s Paint Brush was the only known (for us) GUI software and was the greatest means of entertainment. The instructors taught us only MS-DOS commands and how to Shut Down the computer. Remembering such weird names as DIR, CD, MD, RD, CHKDSK, FDISK, VER, ATTRIB, REN, DEL etc. along with their syntax and usage was a great accomplishment. But I had a problem understanding this: DOS has a separate dedicated command for every action; literally every action, except… creating a file!

Yes, we used COPY CON filename to create a file with name filename. Anyone can say that it is a form of COPY command. So, why was creating a file different than all other commands? I didn’t understand it, till I found out how to print using DOS, almost four years later.

DOS uses different names for the attached devices, I learnt. PRN was one such name. TYPE filename would display the contents of a file and TYPE filename > PRN would print it instead of displaying. Curiosity brings many hidden matters out. PRN would surely mean Printer and will redirect the output to the printer instead of console. Console (monitor) is the implicit default output device, and it can be bypassed if needed. So, how to put it explicitly? There must be some means to do that. Yes, there is! TYPE filename > CON performs exactly same function as TYPE filename. These special names for the devices really mean something special for the operating system and those names can not be used as folder or file names: CON, PRN, NUL, COM1 to COM9, LPT1 to LPT9, which stand for CONsole, PRiNter, NULl, serial COMmmunication ports, Line PrinTer ports.

The time has changed and Operating System can also be fooled! But still, many people think that it is not possible to create a folder by name CON. Using the path of network drive, these special names can also be used as folder names! Here is how:

1. Goto DOS
2. Type MD \\.\C:\CON. The folder will be created. You can check it in Windows Explorer also, but you can’t access it
3. To delete the folder, type RD \\.\C:\CON

In short, use the network path syntax instead of absolute path syntax.

Now on to the practical aspect of this. Why can’t we create it directly but using the network path syntax? The answer is simple. A computer can have only one default console, printer, null etc. So, if it is accessed from a network, theoretically, the console should belong to another node in the network. Since that node may not have a device which can be referred using the name CON, it will no longer be considered as a reserved name. Hence, the folder can be created.

The next time when someone asks the question why we can’t create a folder by name CON, say with confidence that it is not true…

apache web server enabling gzip in linux

Enable the below mentioned modules in Apache

1. Enable the module in httpd.conf
a. LoadModule deflate_module modules/mod_deflate.so
b. Include the lines in httpd.conf
i. SetOutputFilter DEFLATE
ii. AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css             text/javascript application/x-javascript
iii. BrowserMatch ^Mozilla/4 no-gzip
iv. BrowserMatch bMSIEs7 !no-gzip
v. BrowserMatch bMSIE.*SV !no-gzip
vi. BrowserMatch bOpera !no-gzip
vii. Header append Vary User-Agent

2. Enabling the expire header
a. LoadModule expires_module modules/mod_expires.so
b. Include the lines in httpd.conf
i. ExpiresActive On
ii. ExpiresDefault “access plus 10 years”

3. Installing the Xcache
a. I have already informed about the implementation of xcache.

check dsl speed test and

Below links are useful to check speed test in dsl connection

http://www.dslreports.com/speedtest?flash=1

Analyze

Simple steps to configure CVS in Linux

Linux setup a Concurrent Versioning System

(CVS) howto

var tf_clickURL = ‘http://a.tribalfusion.com/h.click/avmyJdWHfXmPYZdncvnodfD3aBk2tim3AfKpFfZd0G3P1sv2XGJvma7V3FQ2Vb7GVPQ2REn1QcUoPWJx0tZbuVAry4sMU0b3DT6im5ABcR6bI4HYsXW3AmHEx3P3V3sngUVQlWVnlS6UMTdJ3YG7h8F9vZcg/http://ad.in.doubleclick.net/clk;182319871;24411341;z?http://www1.ap.dell.com/content/products/productdetails.aspx/inspnnb_1525?c=in&cs=indhs1&l=en&s=dhs&~ck=mn’; var tf_flashfile = ‘http://cdn5.tribalfusion.com/media/1102796/dell1525_300x250.swf’; var tf_imagefile = ‘http://cdn5.tribalfusion.com/media/1102796/dell1525_300x250.jpg’; var tf_width = 300; var tf_height = 250; var tf_background= ‘#ffffff’; var tf_click_command = ‘CLICK’; var tf_ignore_fscommand_args = 0; var tf_use_embedded_flash_url = 0; var tf_append_fscmd_args_to_click = 0; var tf_use_flash_wrapper = 1; var tf_id = ‘2131460576’; var tf_click = ‘http://a.tribalfusion.com/h.click/avmyJdWHfXmPYZdncvnodfD3aBk2tim3AfKpFfZd0G3P1sv2XGJvma7V3FQ2Vb7GVPQ2REn1QcUoPWJx0tZbuVAry4sMU0b3DT6im5ABcR6bI4HYsXW3AmHEx3P3V3sngUVQlWVnlS6UMTdJ3YG7h8F9vZcg/’; var tf_wmode = ‘transparent’; var tf_frame = ‘http://cdn5.tribalfusion.com/media/common/flash/frame2.swf’; var tf_button = ‘http://cdn5.tribalfusion.com/media/common/flash/button2.swf’; function TFclick2131460576_DoFSCommand(command, args){ if (command == tf_click_command2131460576 && tf_use_embedded_flash_url2131460576 == 1) { window.open(tf_click2131460576+args,’_blank’); } else if (command == tf_click_command2131460576 || tf_ignore_fscommand_args2131460576 == 1) { window.open(tf_clickURL2131460576,’_blank’); } }

&amp;lt;A href=”http://a.tribalfusion.com/h.click/avmyJdWHfXmPYZdncvnodfD3aBk2tim3AfKpFfZd0G3P1sv2XGJvma7V3FQ2Vb7GVPQ2REn1QcUoPWJx0tZbuVAry4sMU0b3DT6im5ABcR6bI4HYsXW3AmHEx3P3V3sngUVQlWVnlS6UMTdJ3YG7h8F9vZcg/http://ad.in.doubleclick.net/clk;182319871;24411341;z?http://www1.ap.dell.com/content/products/productdetails.aspx/inspnnb_1525?c=in&amp;amp;cs=indhs1&amp;amp;l=en&amp;amp;s=dhs&amp;amp;~ck=mn&#8221; TARGET=”_blank”&amp;gt;&amp;lt;IMG src=http://cdn5.tribalfusion.com/media/1102796/dell1525_300x250.jpg WIDTH=300 HEIGHT=250 BORDER=0&amp;gt;&amp;lt;/A&amp;gt; <A href=’http://a.tribalfusion.com/h.click/avmyJdWHfXmPYZdncvnodfD3aBk2tim3AfKpFfZd0G3P1sv2XGJvma7V3FQ2Vb7GVPQ2REn1QcUoPWJx0tZbuVAry4sMU0b3DT6im5ABcR6bI4HYsXW3AmHEx3P3V3sngUVQlWVnlS6UMTdJ3YG7h8F9vZcg/http://ad.in.doubleclick.net/clk;182319871;24411341;z?http://www1.ap.dell.com/content/products/productdetails.aspx/inspnnb_1525?c=in&cs=indhs1&l=en&s=dhs&~ck=mn&#8217; TARGET=’_blank’> <IMG src=’http://cdn5.tribalfusion.com/media/1102796/dell1525_300x250.jpg&#8217; WIDTH=300 HEIGHT=250 ALT=’Click Here!’ BORDER=0></A>

Q. I am planning to use Concurrent Versioning System. I am using both Red Hat and Fedora Linux. How do I setup a CVS server?

A. Concurrent Versioning System (CVS) a widely used version control system for software development or data archiving solutions.

From the wiki page, “CVS keeps track of all work and all changes in a set of files, typically the implementation of a software project, and allows several (potentially widely separated) developers to collaborate”.

CVS Configuration – Install CVS

Use rpm or up2date or yum command to install cvs:# rpm -ivh cvs*OR# up2date cvsOR# yum install cvsCreate a CVS user# useradd cvs
# passwd cvsAbove command will create a user cvs and group cvs with /home/cvs home directory.

Configure CVS

Open /etc/profile and append following line:# vi /etc/profileAppend following line:export CVSROOT=/home/cvsSave the file and exit to shell promot.

Make sure your /etc/xinetd.d/cvs looks as follows:# less /etc/xinetd.d/cvsOutput:

service cvspserver
{
       disable            = no
       socket_type    = stream
       wait                = no
       user                = cvs
       group              = cvs
       log_type          = FILE /var/log/cvspserver
       protocol          = tcp
       env                 = '$HOME=/home/cvsroot'
       bind                = 192.168.1.100
       log_on_failure  += USERID
       port                = 2401
       server             = /usr/bin/cvs
       server_args     = -f --allow-root=/home/cvsroot pserver
}

Note: Replace 192.168.1.100 with your actual server IP address.

Restart xinetd:# service xinetd restartAdd users to this group (see this howto for more info)# adduser username -g cvs
# passwd usernameClient configuration
Finally user can connect to this CVS server using following syntax:
$ export CVSROOT=:pserver:vivek@192.168.1.100:/home/cvs
$ cvs loginWhere,

• vivek – username
• 192.168.1.100 – CVS server IP

See also:

• CVS web site and documentation

set passwod in Apache using htaccess

Implement User/Password-protected Directories

DeveloperSide.NET Articles

Important Notes

• Make sure that directory C:\www\Apache2\bin is specified under the System Path variable (if you installed our Web-Server Suite package, this is set). We will use a program named htpasswd.exe, that is contained under the mentioned directory, to create a password file for the specified users.

Create the protected Directory

This section will show you how to create directory “private” outside the Web-Server’s webroot directory “C:\www\webroot” using the command prompt.

Open the Windows command-shell via Start » Run… cmd.exe <click ok>

Change to the drive letter of your Web-Server Suite’s root directory (this is the drive you installed the Web-Server Suite under; for this example we will use drive “C:”)…

...> C:Change to the path of your Web-Server Suite’s root directory (for this example we will use path “\www”)…

C:\...> cd \wwwCreate the directory you want to restrict access to with a user/password prompt (we will create directory named “private”)…

C:\www> mkdir privateChange to your newly created directory…

C:\www> cd private

Create user/password file

Continuing from the previous section, we are now ready to use htpasswd.exe to create a file named “.htpasswd”: this file will contain user names with their respective passwords (the passwords will be encrypted before placed under the file).

This 1st line (with switch “-c” — that will not be repeated in the following lines) will create a file named .htpasswd under the current directory (C:\www\private). The password given will be encrypted by the htpasswd.exe program (due to the “-m” switch — MD5 encryption).

User named “user1” with password “passuser1” is specified 1st…

C:\www\private> htpasswd -cmb .htpasswd user1 passuser1Add user named “user2” with password “passuser2” to the .htpasswd file…

C:\www\private> htpasswd -mb .htpasswd user2 passuser2Add user named “user3” with password “passuser3” to the .htpasswd file…

C:\www\private> htpasswd -mb .htpasswd user3 passuser3

Configuration — httpd.conf

We can now edit Apache’s httpd.conf file to bring everything together.

Edit file C:\www\Apache2\conf\httpd.conf

Make sure that the following two ‘LoadModule’ lines are uncommented, by removing the beginning “#” character…
(These ‘LoadModule’ lines should already be uncommented, by default)

LoadModule access_module modules/mod_access.so
LoadModule alias_module modules/mod_alias.so Uncomment the following two ‘LoadModule’ lines, by removing the beginning “#” character…
(The 1st line is required for directive ‘AuthUserFile’)
(The 2nd line is required for directive ‘Options Indexes’: to display the index of a directory)

LoadModule auth_module modules/mod_auth.so
LoadModule autoindex_module modules/mod_autoindex.so Insert code…

<Files ~ "^\.ht">
   Order allow,deny
   Deny from all
</Files>

Alias /private "/www/private"

<Directory "/www/private">
   Order allow,deny
   Allow from all

   Options Indexes
   AuthType Basic
   AuthName "Private Access"
   AuthUserFile "/www/private/.htpasswd"
   Require valid-user
</Directory>

Save file and Restart Apache…
(from the command prompt type the following)

> net stop Apache2
> net start Apache2

Test protected Directory

Access http://localhost/private/

Enter one of the user/password combinations…
You should now see either the directory structure, or (if you have an index.html\php file under the accessed directory) your index file.
To [truly] logout as the user, you must close the browser window.

Advanced Configurations and Features

You can also grant/restrict access to the user/password protected directory with IP addresses…

Replace the original “<Directory “/www/private”>” block with this updated version…
(or simply replace the first two lines of the original block)

<Directory "/www/private">
   Order deny,allow
   Deny from All

   Options Indexes
   AuthType Basic
   AuthName "Private Access"
   AuthUserFile "/www/private/.htpasswd"
   Require valid-user
</Directory>

Below the line…

Require valid-user

..add the following code…

Allow from 127.0.0.1
Satisfy Any

…if you access the protected area from your local system (IP address — 127.0.0.1), there will be no need to enter a user/password combination.
(Note that you can add multiple “Allow from ip-address” statements to grant access)

…by using the following code instead…

Allow from 127.0.0.1
Satisfy All

Show Hidden Files and Folders not working?

Go to registry editor by running regedit in the run box.
Go to this key:
HKEY_CURRENT_USER\Software\Microsoft\
Windows\CurrentVersion\Explorer\Advanced

In the right hand area, double click hidden and change the value to 1.

Vmware Converter can convert the windows machine as vmware image

VMware Converter provides an easy-to-use, scalable solution for migrations of machines, both physical to virtual and virtual to virtual. Optimized for mass migration, VMware Converter is equally effective for single-machine conversions. With its comprehensive and comprehensible wizards and task manager, VMware Converter imports virtual machines faster, with fewer manual steps required, and fewer source hardware limitations than other methods. With its ability to perform hot cloning, VMware Converter can import a virtual machine with no downtime on the source physical machine.

• Conversion of VMware hardware version 6 products: Workstation 6.x, VMware ACE 2.x, VMware Fusion 1.x, and VMware Player 2.x
• Conversion of an additional third-party disk image format: Acronis True Image 9
• Experimental support for Microsoft Vista 32-bit and 64-bit operating systems
• Ability to set speed and duplex settings on the network adapter while performing cold cloning migrations, by using the VMware Converter Enterprise Boot CD
• Support for Symantec Backup Exec System Recovery 7.0

You can download the vmware converter by using the following link

vmware converter

Security considerations with password authentication in CVS

The passwords are stored on the client side in a trivial encoding of the cleartext, and transmitted in the same encoding. The encoding is done only to prevent inadvertent password compromises (i.e., a system administrator accidentally looking at the file), and will not prevent even a naive attacker from gaining the password.The separate cvs password file (see Password authentication server) allows people to use a different password for repository access than for login access. On the other hand, once a user has non-read-only access to the repository, she can execute programs on the server system through a variety of means. Thus, repository access implies fairly broad system access as well. It might be possible to modify cvs to prevent that, but no one has done so as of this writing. Note that because the $CVSROOT/CVSROOT directory contains passwd and other files which are used to check security, you must control the permissions on this directory as tightly as the permissions on /etc. The same applies to the $CVSROOT directory itself and any directory above it in the tree. Anyone who has write access to such a directory will have the ability to become any user on the system. Note that these permissions are typically tighter than you would use if you are not using pserver.

In summary, anyone who gets the password gets repository access (which may imply some measure of general system access as well). The password is available to anyone who can sniff network packets or read a protected (i.e., user read-only) file. If you want real security, get Kerberos.

CVS Access Control List Extension Patch

CVSACL is a patch for CVS. It adds two new subcommands (acl & racl) to cvs for access control list management. It provides advanced ACL definitions per modules, directories, and files on branch/tag for remote cvs repository connections. Execution of all CVS subcommands can be controlled with eight different permissions.
ACL definitions works for only remote connections, local users can access and modify repository, if unix file system permissions allow. If you want all users to make remote connections to repository, and not allow local users to access repository, you have to set CVSServerRunAsUser keyword in aclconfig file (explained below). Still local users can use acl and racl subcommands to set permissions on directories or files if they have acl admin rights (p) on related directories or files.
So, in order to control all access to repository with this ACL extension, you should use CVSServerRunAsUser keyword and force all users to make remote connections. CVS repository administrator or project managers have to use acl and racl subcommands to manage permissions. But there is no gui client supporting these subcommands, so you have to use cvs client itself either locally or remotely. Download current version 1.2.5 (June 10, 2006)
sourceforge.net project page
cvsacl-announce mailing list
cvsacl-users mailing list
How to install
Permission types
ACL config keywords
Command line usage information
Command line usage samples

Installation

• copy the file acl.c under src directory of CVS source distribution.
  cp acl.c /path/to/cvs-1.11.x/src/
• copy the patch file cvsacl-patch-1.2.x under CVS source distribution directory.
  cp cvsacl-patch-1.2.x /path/to/cvs-1.11.x/
• cd to CVS source directory.
  cd /path/to/cvs-1.11.x/
• apply the patch.
  patch -p0 < cvsacl-patch-1.2.x
• if you are initializing the repository after applying patch, related config files will be created with init command.
  cvs -d /path/to/repository init
• if you already have a repository, you have to add the aclconfig file to your $CVSROOT/CVSROOT/. aclconfig.default is the default configuration file, you can rename it to aclconfig, and use it .
• modify aclconfig file, if you need to change some options.
• as the last step, you have to define yourself as acl administrator.
  cvs -d /path/to/repository racl yourname:p -r ALL -d ALL
  this command gives p (acl admin) rights to user (yourname), on all repository and tags/branches.

Permission Types

• no access
  Command line character: n
  If a user given n permission, it is not allowed for any action on repository.
• read
  Command line character: r
  r permission gives only read access on repository. With r permission you are allowed to run cvs subcommands: annotate, checkout, diff, export, log, rannotate, rdiff, rlog, status.
• write
  Command line character: w
  w permission allows only cvs commit/checkin action. With w permission, you are not allowed to add/remove any file to/from repository, other permissions should be defines for that.
• tag
  Command line character: t
  t permission allows cvs tag and rtag subcommands to run, so you may control tagging and untagging operations. t permission includes r permission, since without reading you can not tag/untag a file. However t permission does not include write permission, you can not commit a file with only t permission.
• create
  Command line character: c
  c permission allows cvs add and import subcommands to run. To add or import a file/directory to repository, you have to given a c permission. Again, c permission does not include write permission, thus you may only add or import files, but you can not modify any existing file. After issuing add subcommand, you have to commit the file to complete adding. This commit subcommand is allowed because you are adding file and not modifying existing one.
• delete
  Command line character: d
  d permission allows cvs remove command to run. To remove a file/directory from repository, d permission have to set. It does not include write permission, so you can not modify contents of an existing file on repository.
• full access except admin rights
  Command line character: a
  a permission gives all access (above permissions) to repository, but it can not modify permissions. Only acl admins may modify the acl definitions.
• acl admin
  Command line character: p
  p permission means that user is an acl admin, so it is allowed to make anything on repository.

ACL Config Keywords

The administrative file aclconfig contains miscellaneous settings which affect the behaviour of ACL extension. Currently defined keywords are:

UseCVSACL=valueUse ACL definitions if set to yes. If you do not want to use ACLs for some repositories in a patched CVS server, set this keyword to no. The default is no.

UseCVSACLDefaultPermissions=value Value can be any combination of valid permission types (w,r,t,c,d,t,a,p). if there is no defined ACL and default permission in access file, or no access file at all, this permissions are used. The default is p (admin rights), if aclconfig file is created with cvs init.

UseCVSGroups=valueCVS does not have a CVSROOT/passwd file. However it can be created manually (format should be same as /etc/group). If value set to yes, CVS checks for groups in file $CVSROOT/CVSROOT/group The default value is no.

UseSystemGroups=valueGroup memberships for users are checked in file /etc/group, if value is set to yes. The default value is no.

CVSACLFileLocation=valueOriginally access file is put under CVSROOT/CVSROOT, if you want a different location, set value to a valid path. The default value is $CVSROOT/CVSROOT/access.

CVSGroupsFileLocation=valueIF UseCVSGroups is set to yes, CVS looks for a group file under $CVSROOT/CVSROOT. To use a different location for group file set value to a valid path to group. The default value is $CVSROOT/CVSROOT/group.

UseSeparateACLFileForEachDir=valueIf value is set to yes, a separate ACL file (access) is created for each directory in repository. If you have a really big repository (directories>10,000 and files>100,000), performance may drop due to a big acl file, access. Setting the value to yes, may increase performance. Normally, you will not need this. The default value is no.

CVSServerRunAsUser=valueSet CVSServerRunAsUser keyword to a valid system user.
Keyword iseffective only in PServer connections. When a user make a remote pserver connection to CVS, after successfull authentication cvs process switch to run as that user, or defined system user in $CVSROOT/CVSROOT/passwd. So, you also have to set unix file permissions accordingly.
A better solution:
Add a user and group such as both cvsadm.
Set CVSServerRunAsUser keyword to cvsadm.
Change unix file system permissions for your repository,
make cvsadm user and group owner, and read,write,execute permissions and setgid.
(chown cvsadm -R /path/to/your/repository)
(chgrp cvsadm -R /path/to/your/repository)
(chmod 2770 -R /path/to/your/repository)
Add yourself to cvsadm group (since you are ACL administrator).
Therefore, only users making remote connections will have access to repository if you give rights. Local users can not access to repository via a cvs client or directly.

Command Line Usage Information

acl command is used on checked out files or directories. racl command is used on repository without a working copy. Usage information can be obtained with standard cvs –help command.
Output of cvs –help acl and cvs –help racl:

Usage: cvs racl [user||group:permissions] [-Rl] [-r tag] [directories...] [files...]
        -R      Process directories recursively.
        -r rev  Existing revision/tag.
        -l      List defined ACLs.

Usage: cvs acl [user||group:permissions] [-Rl] [-r tag] [directories...] [files...]
        -R      Process directories recursively.
        -r rev  Existing revision/tag.
        -l      List defined ACLs.

NOTICE: There is no more -d -f options for directory and files, acl/racl subcommands runs like other cvs subcommands.

You may directly set permissions for a user or group or add/remove permissions with + and – signs to/from existing permissions.
If you do not give the branch/tag information, default value of HEAD (main branch) will be used. You have to give branch/tag name with -r option. You may type ALL for branch/tag field.

While checking for permissions, it goes thorough the list below. So the highest significant permission is the first item in list.

• permissions assigned to username for specific directory or file.
• permissions assigned to group name for specific directory or file.
• permissions as defaults for specific directory or file.
• permissions as repository defaults.
• permissions in aclconfig file.

Examples

     /cvs/
      |
      |
      +--projectA/
      |	       |
      |        +---CVSROOT/
      |        |
      |        +---lib/
      |        |     |
      |        |     +---gnulib/
      |        |     |
      |        |     +---zlib/
      |        |
      |        +---src/
      |        |     |
      |        |     +---main.c
      |        |     |
      |        |     +---server.c
      |        |     |
      |        |     +---client.c
      |        |
      |        +---gui/
      |
      +--projectB/

We have above directory structure for a cvs repository, and no defined permissions.

Setting main default permissions:

$ cvs -d /cvs/projectA racl cvsadmin:p -r ALL ALL
$ cvs -d /cvs/projectA racl ALL:r -r ALL ALL
User cvsadmin will be an acl admin, and all other users will have only read rights on all branches/tags in projectA repository. This is the default acl definition and it overwrites default permissions in $CVSROOT/CVSROOT/aclconfig file.

$ cvs -d /cvs/projectA racl ALL:r -r ALL ALL
$ cvs -d /cvs/projectA racl ALL:n -r ALL gui
After executing these two commands, all users will have read access on all directories and files except gui directory. Everyone will be denied to access to gui directory becase no access, n, permissions is set.

Setting permissions directly on a file or directory:

$ cvs -d /cvs/projectA racl userX:wcd lib
$ cvs -d /cvs/projectA racl group1:w lib
First command will set write, create, and delete permissions for userX on directory lib with branch HEAD (since no branch/tag information given, branch defaults to HEAD). Second command will set only write permission for group1 on directory lib with branch HEAD. Members of group1 will have only commit rights on lib directory, branch HEAD, they can not add or remove any file, just modify existing files.
If userX is also a member of group1, userX will have write, create, and delete permissions because it is specifically given these permissions.

$ cvs -d /cvs/projectA racl userY:wcd -r develStream lib
$ cvs -d /cvs/projectA racl userY:r -r integStream lib
These commands will give wcd permissions to userY on lib directory with tag develstream, and r permissions on lib directory with tag integStream.

$ cvs -d /cvs/projectA racl userZ:wcd src
$ cvs -d /cvs/projectA racl userZ:r src/main.c
First command will give wcd permissions to userZ on src directory, but only read permission on file main.c in src directory.

Using + and – signs to set permissions on a file or directory:

$ cvs -d /cvs/projectA racl userZ:+t src
$ cvs -d /cvs/projectA racl userZ:-cd src
$ cvs -d /cvs/projectA racl userZ:-wt src
Before the first command, userZ has wcd permissions on src directory, after issuing command it will have wcdt permissions. Tag permission will be added. UserZ has wcdt permissions, and we execute the second command to remove create and delete permissions. So userZ has wt permissions. In the last command we also remove wt permissions, finally userZ has no defined permissions left, and it will use the default permissions if set.

Listing permissions on a file or directory:

$ cvs -d /cvs/projectA racl -l src
$ cvs -d /cvs/projectA racl -l src
$ cvs -d /cvs/projectA racl -l src/main.c

First command will list the permissions for src directory.
Example output:
d src HEAD | userX:wcd group1:r | defaults:r
userX and group1 has assigned permissions, all other users will have default permissions, which is only read.

Second command will list the permissions for files in src directory.
Example output:
f src/main.c HEAD | userX:wcd group1:r | defaults:r
f src/server.c HEAD | userX:wcd group1:r | defaults:r
f src/client.c HEAD | userX:wcd group1:r | defaults:r

Third command will list the permissions for main.c file in src directory.
Example output:
f src/main.c HEAD | userX:wcd group1:r | defaults:r <!–

CVS server main site
WinCVS – a visual CVS client for Windows
jCVS – a visual CVS client, OS independent
–>