Have been playing around with Nikola on and off for a few months now, finally decided it was time to move away from PHP and Wordpress and try my hand it a PHP free environment, so welcome to the first post generated by Nikola.
In goes content, out comes a website, ready to deploy.
Static websites are safer, use fewer resources, and avoid vendor and platform lock-in. You can read more about this in the Nikola Handbook.
Get started with Nikola now, below can be done on most linux systems as well as OSX, rember do the following as a user, not
virtualenv ~/.python . ~/.python/bin/activate pip install nikola nikola init mysite cd mysite nikola new_post nikola build nikola serve
If you have no issues with above, then you should be able to see your new site at http://127.0.0.1:8000
Now go forth and make PHP free blogs.
So you want to add LDAP support to PHP 5.x while your server has cPanel installed, As a cPanel user your go to tool would EA (easyapache).
However easyapache has no native selection for LDAP. This means we gonna have to ninja support in by way of adding some RAWOPTS to the build.
SSH to server as root.
Add the line "--with-ldap" to the file: /var/cpanel/easy/apache/rawopts/all_php5. Then kick off EA.
vim /var/cpanel/easy/apache/rawopts/all_php5 /scripts/easyapache --build
Once All done, run php -m to see if the module is installed, if not in the list make sure openldap-devel is installed and try again. ::BASH php -m |grep --color ldap
If you still dont come right look at the logs of the last EA build in "/usr/local/cpanel/logs/easy/apache/build.*", look at the most recent log.
ls -altr /usr/local/cpanel/logs/easy/apache/build.*
I recently migrated a SELINUX enabled server to new hardware. Once the sync of the data was completed I configured the server to boot. What soon followed was almost an hour of reboots and remounts in rescue mode. See the server would boot but I was unable to login as I would get this lovely error:
login: no shell: permission denied
Yay, I says. Right so after some interwebz trawling I cam across a lone post on some forum on how to fix the issue. As with most forums you need to wade through the crap before you find what you need.
The poster suggested I mount the drive from a centOS rescue environment and run the below command.
# make sure you touching .autorelabel on the root partition of the new drive. touch /mnt/sysimage/.autorelabel
Once the file has been touched , bounce the server (reboot it) and the server will boot and relabel all SELINUX related files and reboot its self.
Over a couple of beers one fine evening, myself a fellow Geek were talking about server hosting. He mentioned that he had LAMP server at Amazon Web Services other wise know as AWS and he was pretty happy with his setup, which at the time got me wondering how his setup would perform under load, not in any mood or state to setup a test server I thought I leave it till the next day.
After some tinkering and choosing the right OS images I wanted, I had a fully functional server up and running and serving pages. Opening up yee old Skype I then began to gloat about my fine achievement to fellow Geeker whom I had a few beers with. Conversation started south like it normally does then moved on to more serious matters, server performance.
The test was simple test of hitting the server with 250 concurrent connections for 60 seconds, Thus telling us how many requests apache can server in a 60 second period.
Our test server has 600Mb of Ram, 10Gb of space and 1 Intel(R) Xeon(R) CPU E5430 @ 2.66GHz core. The sever has been setup with Ubuntu 10 running Apache2 with PHP 5.3 and MySQL 5.x. Apache is hosting one website running WordPress with a few addons. Setting all this up only costs time as AWS does not charge for MINI instances - more on that later.
On the first test we made no changes to the server setup as previously stated, lets see how we fair.
Blitz.io Rush Test: 12 hits, 7,004 timeouts
This rush generated 12 successful hits in 1.0 min and we transferred 479.67 KB of data in and out of your app. The average hit rate of 0.30/second translates to about 25,515 hits/day.
We have bigger problems though: 99.83% of the users during this rush experienced timeouts or errors!
The first timeout happened at 5.41 seconds into the test when the number of concurrent users was at 23. Looks like you've been rushing with a timeout of 1 second.
While the test had finished the server had panicked and fell over , we then had to a hard reboot to get the damn thing back, SSH session gave in, the load shot up to 80 , below screenshot is what we managed to get from the server before it went awol.
From the previous test we learnt that the web server was never going to cope with being slashdotted. So I suggest lets slap on the WordPress addon called SuperCache to WordPress. SupperCache basically makes a WordPress site static thus using PHP and mysql a lot less. Yeah, this sounds like a good plan, lets go with it.
Once SuperCache was installed, we were ready to go.
Blitz.io Rush Test: 1,207 hits, 5,805 timeouts
This rush generated 1,207 successful hits in 1.0 min and we transferred 42.84 MB of data in and out of your app. The average hit rate of 6.57/second translates to about 567,354 hits/day.
We have bigger problems though: 82.79% of the users during this rush experienced timeouts or errors!
The first timeout happened at 31.39 seconds into the test when the number of concurrent users was at 131. Looks like you've been rushing with a timeout of 1 second.
Load of the server only went up to about 3, so this is way better then running the server with no Caching. However we still dropping requests , in turn loosing visitors.
So from previous test we know our setup is still not optimal, so we have two choices.
Now being lazy and not wanting to spend hours tweak the LAMP setup I opted to use Varnish and here are the results. Strap in as you will be amazed at the performance gain we got.
Blitz.io Rush Test: - 7,270 hits
This rush generated 7,270 successful hits in 1.0 min and we transferred 257.93 MB of data in and out of your app. The average hit rate of 116/second translates to about 10,048,702 hits/day.
Not one timeout happened, the server servered all 7,270 requests - amazing.
The Load of the server did not peak past 0.5, in the excitement I toke late screenshot.
I could crap on about how awesome Varnish is for the next 10 pages, but I am not going to. All I am going to say is Varnish is awesome and this is the proof. But the biggest Con about Varnish is it requires loads of tweaking to get right, we were just luck that WordPress works beautifully with Varnish.
SSH is an awesome tool which can be used for good and evil, the good being connecting to servers via an encrypted tunnel, thus allowing you to do sensitive work on servers which you would not like in plain text, like a telnet session.
The Evil, well now their are many evils that ssh can be used for and I am not gonna get into them right now, except maybe this one. 1
Creating a SSH tunnel in order to browse the interwebz 2 could be considered evil especially when you are circumventing corporate internet usage. This could lead to you being fired or having a grumpy sys-admin type blocking all your access. In saying that don't hold me liable for what you do with this guide.
However if you need a good reason to use this guide , I would say use it when you really need to download some urgent security updates, when your local service provider has limited upstream bandwidth or testing a website from another country that geo location data.
What you need for this guide.
Once above criteria is meet, lets get started.
First thing to do is open a terminal, quickest way to do this by bringing up spotlight ( CMD+SPACEBAR ) and typing terminal.
Once you have terminal open, type the following command, as reference I will break the command down so we can understand what we are going to do.
ssh -p 22 -v -N -D 8888 email@example.com
-p 22 = ssh on port 22 , this can be changed if you running ssh server on a different port. -v = ssh will be verbose, nice to have as we can see what traffic is be forwarded. -N = Do not execute a remote command. This is useful for just forwarding ports -D 8888 = Specifies a local ``dynamic'' application-level port forwarding. firstname.lastname@example.org = The username and host you will be connecting to.
The connection can be stopped at any time by hitting CTL+C or by closing the terminal, but don't forget to change the proxy settings back, else you be left with an internet less connection.
Moving along we need to configure OSX to use the newly created tunnel. I am not going to to be that descriptive about what we are doing , so just follow the pictures, it will all make sense soon.
Open up System Preferences and type Proxies in the search area and hit enter.
In the next window , tick SOCKS proxy and fill in the SOCKS proxy details on the right. In this example server will be localhost and port will be 8888
Click OK and Apply.
Now all that we need to do is test it, best way to do that is open a browser and goto WhatsMyIP. If all worked well then you should see the IP of the server you SSH'ed to.
Now be responsible and try not to do this to circumvent your corporate Firewall Policies.
If you wish to convert from CentOS 5.x to CloudLinux, have already installed cPanel & WHM, and own an IP-based CloudLinux license, run these commands:
/usr/local/cpanel/cpkeyclt /usr/local/cpanel/bin/cloudlinux_system_install -k
Reboot the server.
shutdown -r now
Once server is backup rebuild apache, this is a good time to install missing php modules.
Once done install kernel-devel as you may need for any custom linux modules.
yum install kernel-devel
Occasionally some management tasks need to be done on postfix, I often forget the commands, thus this post came to life. I will add more commands when I use them.
postcat -q [queue_id]
postsuper -d [queue_id]
postsuper -d ALL
In my IT adventures I was asked to do a restore of a mysql table, however I was unable to restore the whole table as I only need to roll back specific content, not the whole table.
To paint the picture , we have table with 3 columns, ID DATA_ID CONTENT as the create syntax shows below, nothing special going on.
CREATE TABLE `temptbl` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `DATA_ID` int(11) DEFAULT NULL, `CONTENT` varchar(64) DEFAULT NULL, PRIMARY KEY (`ID`) ) ENGINE=MyISAM DEFAULT;
Now the common column we are looking at is DATA_ID as this will be the row of data we need to restore, its a our reference point for the WHERE clause we are going to use next. Knowing how the table is structured is key.
Once we have the DATA_ID of the user we could then dump from a backup of the database that was done a few hours before - I hope you have a backup.
Take the backup and import into a new database , I have outlined some basic commands below on how to import the mysql backup:
mysqladmin create tempdb mysql tempdb < db-backup.sql
Ok good we now have the backup copy of the database loaded we are ready to go.
Now lets dump the data we want with mysqldump adding a nice where statement.
mysqldump --no-create-info --skip-opt tempdb table --where="DATA_ID=1234"
you will get an output that looks like this:
-- -- Dumping data for table temptbl -- -- WHERE: DATA_ID=1234 INSERT INTO temptbl VALUES (1,1234,'some content'); INSERT INTO temptbl VALUES (2,1234,'moar content'); INSERT INTO temptbl VALUES (3,1234,'blah');
Once you are happy with the INSERT information from above, you can import it back in to the live database, I suggest removing all references to DATA_ID first and then importing the dump from before.
This can be done in 2 lines of bash.
mysql tempdb -e "delete from table where DATA_ID=1234" mysqldump --no-create-info --skip-opt tempdb table \ --where="DATA_ID=1234" |mysql tempdb
There you have it , nice quick and easy restore for the data you only want.
The database structure above is just an example, so in most case's this wont work if you just copy and paste commands, study your database first and always work from backup.