Monthly Archives: September 2014
Document show how to set up basic fature of pakage and push to clients.
After installation, how to Roll back patches in windows
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
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
System partitions rapidly filled and get drive warnings all the times.
Chances to server crashes.
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
yum install httpd
yum -y install subversion mod_dav_svn
mkdir -p /var/www/svn/repository
svnadmin create test_svn
chown -R apache.apache svn
lsof | grep svn
strings activities.pag |less
svnadmin list-dblogs /var/www/svn/repository/
svn co /var/www/svn/repository/test_svn/
#command to type svn as a service
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
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/
repobrowser open create dir-create files
then svn commit
svn update after changing
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
PHP 5 + Pear (VersionControl_SVN)
Stickey session means ensuring requests can be automatically routed to the same Real Server for handling as the initial request from the same source.
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
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:
Weighted round robin
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.
Below document shows setup Zamanda for S3