Perforce branch locking

You can lock Perforce branch,depot or any other folder by using either
1) Protection table
2) Triggers

Using protection table:
You can lock a branch by just creating a new rule in Protection table. For example here, we are locking a branch called //dev/envision/esi/... by just providing only read permission to group xxx

read group xxx * -//dev/envision/esi/...


Here is a complex example.
The below protection table locks the branch //release/envision4.1sp1/... for every one else, except the user xxxats2. It locks for all the concerned groups release-xxx-4.0, xxx, yyy-group, yyy-all

                =write group release-xxx-4.0 * -//release/envision4.1sp1/...

                =write group xxx * -//release/envision4.1sp1/...

                =write group yyy-group * -//release/envision4.1sp1/...

                =write group yyy-all * -//release/envision4.1sp1/...

                write user xxxats2 * //release/envision4.1sp1/...

                =write group ddds * -//user_information/enVision/4.1_SP1/output/...

                =write group uuuu-info * -//user_information/enVision/4.1_SP1/output/...

                =write group yyy-all * -//user_information/enVision/4.1_SP1/output/...

                write user xxxats2 * //user_information/enVision/4.1_SP1/output/...

Points to remember:

• The protection table order works from bottom to top. Hence place new locking rules below the existing rules in order for it be in effect.
• =write : means, provide all other privileges ( like read, open), except write
• Use "p4 protects //release/envision4.1SP1/..." command to find out which all groups/users already have write privileges. Remove write privileges from all the concerned groups

Using triggers:
You can also lock a branch by writing a changelist submission trigger of type change-submit. Here the trigger logic work something like, when a changelist comes for submission, check for files under branch which you want to lock and also check for some .lock file created in a location accessible to server. If .lock file is present then cancel change submission.
Cons: This will definitely slowdown the CL submission time.

Read More

Setting up NFS server (Fedora core10) and client on FC6

NFS means Network File System. NFS allows a system to share directories and files with others over a network. By using NFS, users and programs can access files on remote systems almost as if they were local files.
Benefits of NFS:
*) Local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network.
*) There is no need for users to have separate home directories on every network machine. Home directories could be set up on the NFS server and made available throughout the network.

How NFS Works?
NFS consists of at least two main parts: a server and one or more clients. The client remotely accesses the data that is stored on the server machine. In order for this to function properly a few processes have to be configured and running.
The server has to be running the following daemons: portmap or rpc.portmap, rpc.nfsd, rpc.lockd, rpc.statd, rpc.mountd, rpc.rquotad.

Configuring NFS Server
Through Gui: Redhat & Fedora distributions provide a GUI interface to setup NFS server.
Just type "system-config-nfs" on a terminal to invoke GUI setup. Then click "Add" Button at top left. Provide directory which you want to share and allowed hosts. In case if you don't want to restrict hosts, then type "*" in hosts field. Select permissions read-write/read-only and then click "ok".

Through command line:
Edit /etc/exports file. An entry in /etc/exports will typically look like this:
directory machine1(option11,option12) machine2(option21,option22)

Example: /opt *(rw,sync)

To make more robust, you can configure optional files /etc/hosts.allow and /etc/hosts.deny

After this make sure daemons portmapper, nfsd is running in your system ("rpcinfo -p" command will help you in this regard). Then run the command "exportfs -ra" to force nfsd to re-read the /etc/exports file.

For more details refer http://www.linux.org/docs/ldp/howto/NFS-HOWTO/server.html


Configuring NFS Client:

Mounting remote directories:
Make sure portmapper and optional rpc.statd, rpc.lockd daemons running on your system. With these daemons running, you should now be able to mount the remote directory from your server just the way you mount a local hard drive, with the mount command.For example
mount master.foo.com:/opt /mnt/opt or
mount -t nfs master.foo.com:/opt /mnt/opt

The standard form of the mount command, is
mount -t type device dir
where -t vfstype( file system types)

Windows mount: mount -t cifs //128.222.180.22/channel /mnt/envision -o username=,domain=corp

Getting NFS File systems to be mounted at boot time:
NFS file systems can be added to your /etc/fstab file the same way local file systems can, so that they mount when your system starts up. The only difference is that the file system type will be set to nfs and the dump and fsck order (the last two entries) will have to be set to zero. For example
cat /etc/fstab
# device mountpoint fs-type options dump fsckorder
10.31.251.75:/export/kits/envision /export/kits/envision nfs defaults 0 0

Then run "mount -a" command and also if require umount

Details: http://www.higs.net/85256C89006A03D2/web/PageLinuxNFSClientSetup. and also man mount

Read More

Knowing processor information from Solaris Box

Solaris provides a command called psrinfo which displays information about processors.

For example to know whether your system runs on AMD or Intel processor, run this command with following arguments

bash-3.00# psrinfo -p -v
The physical processor has 1 virtual processor (0)
x86 (GenuineIntel family 15 model 4 step 8 clock 3391 MHz)
Intel(r) Xeon(tm) CPU 3.40GHz


As always, try out man psrinfo for detailed information.

Read More

How to expand vmware disk space?

You can expand vmware disk space in already installed VM Workstation by using a utility called vmware-vdiskmanager. This utility can be found in your VMWare Workstation installation directory i.e C:\Program Files\VMware\VMware Workstation.

Suppose if you want to increase your disk space from 8GB to 15 GB, then run this command as given below

vmware-vdiskmanager.exe -x 15Gb "Red Hat Enterprise Linux 4.vmdk"

Here the last argument needs to be replaced with your own .vmdk file for which you need to increase it's size.

If every thing goes well the output from above command will be
-----------------------------------------------------------------------------
O/P:
Using log file C:\DOCUME~1\guruss1\LOCALS~1\Temp\vmware-guruss1\vdiskmanager.log
Grow: 100% done.
The old geometry C/H/S of the disk is: 1044/255/63
The new geometry C/H/S of the disk is: 1958/255/63
Disk expansion completed successfully.

WARNING: If the virtual disk is partitioned, you must use a third-party
utility in the virtual machine to expand the size of the
partitions. For more information, see:
http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1647

-----------------------------------------------------------------------------

Make sure you logged out from your workstation when you execute this command.

For more help run "vmware-vdiskmanager -help"

Read More

Use of .PHONY targets in Makefiles, an example

Targets that do not represent files are known as phony targets. Examples are standard phony targets such as "clean", "all". It also makes a target always out of date.

It is important to note that make cannot distinguish between a file target and phony target. If by chance the name of a phony target exists as a file, make will associate the file with the phony target name in its dependency graph. If, for example, the file clean happened to be created running make clean would yield the confusing message:
$ make clean
make: `clean' is up to date.

Since most phony targets do not have prerequisites, the clean target would always be considered up to date and would never execute.

To avoid this problem, GNU make includes a special target, .PHONY, to tell make that a target is not a real file. Any target can be declared phony by including it as a prerequisite of .PHONY:
.PHONY: clean
clean:
rm -f *.o

Now make will always execute the commands associated with clean even if a file named clean exists.

Here is a simple Makefile which demonstrates the problem and solution
------ Makefile --------------------------
all: print
print:
cat clean
clean:
rm *.o
--------------------------------------------
If you just call make, it outputs the contents of "clean" file present in the current working directory.
For Ex:
[siddesh@jadoo phony]$ make
cat clean
This is a clean script

Suppose if you want to run clean target to remove .o files, then you need to run "make clean". But you woudn't be getting desired output. Lets see what it reports

[siddesh@jadoo phony]$ make clean
make: `clean' is up to date.

Corrected Makefile
------------------------------------------
all: print
print:
cat clean

.PHONY: clean
clean:
rm *.o
--------------------------------------------
Now if you try "make clean", it will call clean target to clean .o files
[siddesh@jadoo phony]$ make clean
rm *.o

Read More