Monthly Archives: September 2014

Install Symantec Basic feature to Clients

Document  show how to set up basic fature of pakage and push to clients.


Rollback installed patches

After installation, how to Roll back patches in windows

How to Rollback installed patches

Better approch to organize disk partitions

Separate your operating system from your data by creating two disk partitions.

Leave Windows and your programs on the C: partition.This will get filled with latest update each month when patching the servers and also temporary files are in the systems partition,so it will rapidly change size, potentially making a file system full.

Applications,need to be installed on different drives.

If the server is using for DataBase,put data files on another drive. Also for using high end applications such as DataBases configure page file(pagefile.sys) on different drive(do remember your system will not boot ,if the drive has delete).

Theoretically a, page file should be 1.5 times the RAM available on server however,
practically it’s not always feasible to set huge amount of page file on server as it
requires very large disk space configured with more RAM. For the server’s with heavy amount of RAM, you might want to limit the Page File size equal some GB at least.
Benefit for this approches

If you keep Windows and your programs in one partition and your data files in another,
you’ll be able to make restorations faster and more easily.

I/O read /write speed will be faster than from a single drive.

Increased Security – There is increased data security, since your data is now on another
partition. Malware that affects or scan files on only one single drive will not scan your
data partition.

Improved Performance – you can defragment your OS drive for max performance, and not worry
about it being fragmented so fast, since data (where it changes the most), resides on
another partition.

System partitions rapidly filled and get drive warnings all the times.
Performance issues.
Chances to server crashes.

Bash Vulnerability

A new security vulnerability known as the GNU Bash or Shellshock bug could be make a major disaster to systems and Web hosts and even Internet-connected devices.

In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable “just on port 80″—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion webpages that at least partially fit the profile for the Shellshock exploit.

Ars Technica reports that the vulnerability could affect Unix and Linux devices, as well as hardware running Max OS X. According to Ars, a test on Mac OS X Mavericks (version 10.9.4) showed that it has “a vulnerable version of Bash”.

CVSS Severity (version 2.0):
CVSS v2 Base Score:10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 10.0
CVSS Version 2 Metrics:
Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service

Robert Graham Blog


GitHub Post

Ars Technica Post


SVN installation under linux

yum install httpd
yum -y install subversion mod_dav_svn
mkdir -p /var/www/svn/repository
cd /var/www/svn/repository
svnadmin create test_svn
chown -R apache.apache svn
vim subversion.conf
vi /etc/httpd/conf/httpd.conf
/etc/init.d/httpd restart
cd /var/www/svn/repository/
vi activities.
vi activities.dir
vi svnserve.conf
lsof | grep svn
strings activities.pag |less
svnadmin help
svnadmin list-dblogs
svnadmin list-dblogs /var/www/svn/repository/
svn co /var/www/svn/repository/test_svn/
svn status
#command to type svn as a service
svnserve -d
ps -ef|egrep -ir svn
rpm -ql subversion
rpm -ql subversion|egrep -ir init
rpm -ql subversion|egrep -ir init|less
rpm -ql subversion|egrep -ir scri
ps -ef|egrep -ir svn
netstat -anp|less
svn co  http://svnadmin:svnadmin@localhost:3690/test_svn
svn co file://var/www/svn/repository/test_svn/
svn co file:///var/www/svn/repository/test_svn/
svn update

client(tortoise svn)
svncheckout(add url-
repobrowser open create dir-create files
then svn commit
svn update after changing

SVN Manager

SVNManager is a web based tool to administer a Unix/Linux Apache WebDAVSubversion repository server.

With this tool you can remotely:

Create, remove, load and dump repositories
Manage user accounts for access to the repositories
Manage groups for acces to the repositories
Invite users by email to create an account on the server

Please use the documentation inside the package, I’m working on a new install guide!
Windows or Unix operation system
Apache 2
PHP 5 + Pear (VersionControl_SVN)

SVN Manager Documentaion

Difference between Stickey and Affinity in Load Balancer

Stickey session means ensuring requests can be  automatically routed to the same Real Server for handling as the initial request from the same source.

Session enhances application performance by using in-memory caching, not a database. Session affinity uses cookies to track session information and, potentially, to maintain login credentials.

Different Vender have different machanism for identifing either through the use of an HTTP cookie or a CIDR netmask.

Affinity: this is when we use an information from a layer below the application layer to maintain a client request to a single server

Persistence: this is when we use Application layer information to stick a client to a single server

sticky session: a sticky session is a session maintained by persistence

The main advantage of the persistence over affinity is that it’s much more accurate, but sometimes, Persistence is not doable, so we must rely on affinity.

Using persistence, we mean that we’re 100% sure that a user will get redirected to a single server.
Using affinity, we mean that the user may be redirected to the same server

Load Balancers

A load balancer is a device that acts as a reverse proxy and distributes network or application traffic across a number of servers. Load balancers are used to increase capacity (concurrent users) and reliability of applications. They improve the overall performance of applications by decreasing the burden on servers associated with managing and maintaining application and network sessions, as well as by performing application-specific tasks.

Load balancers are generally grouped into two categories: Layer 4 and Layer 7. Layer 4 load balancers act upon data found in network and transport layer protocols (IP, TCP, FTP, UDP). Layer 7 load balancers distribute requests based upon data found in application layer protocols such as HTTP.

Requests are received by both types of load balancers and they are distributed to a particular server based on a configured algorithm. Some industry standard algorithms are:

Round robin
Weighted round robin
Least connections
Least response time

Layer 7 load balancers can further distribute requests based on application specific data such as HTTP headers, cookies, or data within the application message itself, such as the value of a specific parameter.

Load balancers ensure reliability and availability by monitoring the “health” of applications and only sending requests to servers and applications that can respond in a timely manner.

Importing Cloud Certificate to setup ZCB with Amazon S3 storage

Below document shows setup Zamanda for S3

Importing Cloud Certificate to setup ZCB with Amazon S3 storage

extending and spanning disks

Below is a document to show how extend or spanning the disk.

extending and spanning disks

%d bloggers like this: