To find files on a linux system you can use following command: # find / -name xxxx But I prefer to use the locate command. This command is extremely easy to use and it’s faster than the find-command. # locate filename To install the locate package, use yum. # yum install mlocate To update it’s ‘internal database’, run following command. # updatedb To find a file, use following command # locate httpd.conf /etc/httpd/conf/httpd.conf  

In Tomcat 7, the password in the setting file: tomcat-users.xml is displayed as string encrypted by md5. In server.xml file: <Realm className="org.apache.catalina.realm.LockOutRealm"> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" digest="md5"/> </Realm> echo -n yourpassword | md5sum make sure you change the password in tomcat-users.xml with md5 encrypted string.

Use "nginx -t" to debug nginx issues. It's a known issue when nginx fails to start in Vesta due to some misconfiguation occurred by itself. nginx: [emerg] the same path name "/var/cache/nginx/xxx.es" used in /etc/nginx/conf.d/01_caching_pool.conf:2 and in /etc/nginx/conf.d/01_caching_pool.conf:3 nginx: configuration file /etc/nginx/nginx.conf test failed nginx: [emerg] the same path name "/var/cache/nginx/xxx.es" used in /etc/nginx/conf.d/01_caching_pool.conf:2 and in /etc/nginx/conf.d/01_caching_pool.conf:3 nginx: configuration file /etc/nginx/nginx.conf test failed [[email protected] ~]# cat /etc/nginx/conf.d/01_caching_pool.conf proxy_cache_path /var/cache/nginx/xxx.com levels=2 keys_zone=xxx.com:10m inactive=60m max_size=512m; proxy_cache_path /var/cache/nginx/xxx.es levels=2 keys_zone=xxx.es:10m inactive=60m max_size=512m; remove all the duplicate lines. And then restart nginx.

  You just got your new CentOS dedicated server, and you notice that times in your logs aren’t quite right. You check the time from the command line (run date), and find that the timezone is set to US Eastern or some other timezone. How do you get this changed? Unfortunately, this is not an easy thing to figure out. Fortunately though, it’s not hard to do with the right directions. Please note that you have to have root access to be able to make the changes detailed below. There are a series of time zone files located at /usr/share/zoneinfo. Select the appropriate named timezone for your location. For my location, Oklahoma, USA, I actually have two that I can select from: America/Chicago or US/Central. Make note of the appropriate folder and file for your timezone. The active timezone used on your system is in the /etc/localtime file. The default will vary depending on your server host but often seems to be EST or EDT (depending on the time of year you are checking). We simply need to replace this file with the file we selected in the previous step. Now, I say replace, but I actually recommend creating a link to the pertinent file rather than actually making a copy. Let me explain the reasoning for this quickly. A crucial part of the timezone shift calculations is the daylight savings calculations. Many people don’t realize this, but the daylight savings days were changed in 2007. When this change happened, all servers needed to be updated with new zoneinfo files.…

Introduction As will be shown, the SSD benchmark testing “lies” are more ones of omission than of commission. But despite honorable intentions, any result must be considered a “lie” when it provides meaningless or, worse yet, misleading information. The underlying cause of these lies is a familiar one: accurate testing takes time. So short-cuts are taken. Important procedures get skipped. Key considerations are ignored. Results are read before performance stabilizes. Important tests are run without proper preparation—or not run at all. The situation with performance testing of solid state drives is not unlike what occurred when the U.S. Environmental Protection Agency (EPA) introduced its gasoline mileage rating system in the 1970’s. The test simulations were not representative of the way most people drive, so the results were notoriously high. Virtually no one got the highway or city mileage “determined” from the testing, while the regulators and auto manufacturers alike acknowledged, yet completely ignored the problem. Subsequent enhancements have dramatically improved the accuracy of the results, but the changes were slow in coming. For example, highway speed limits increased from 55 to 65 MPH in 1987, but the EPA tests did not take this into account until the 2008 model year—21 years later! The “your mileage may vary” caveat applies equally to SSD benchmark testing today. Some testing is robust, with the results providing an accurate prediction of the performance that might be expected in the real-world. More likely, the results are way off, way too often. Here are the three key factors that determine whether or not SSD benchmark testing…