Disable 802.11n  and downgrade to g on your wireless access point.

 (Not an exceptable answer to me due to the fact I have other products running n that have no issues. Why should I suffer on these devices because my laptop fails to run on it.)

And the other solution I was able to hunt down which is the one I am using until a fix for the issue surfaces which involves forcing iwlagn to not use n. Before making the change permanant run the following commands from a console window. The commands will disable n on the device without making it a permanant change to see if this fix will actually work for you before editing files. If this solution don’t work a simple reboot will bring you back to where you were.

sudo rmmod iwlagn
sudo modprobe iwlagn 11n_disable=1

If after running the above commands you notice greatly improved speeds then you can make them permanent by doing the following.

sudo nano /etc/modprobe.d/options.conf

Then add the following line to this file.

options iwlagn 11n_disable=1

First you will need to download the latest version of XDebug from http://xdebug.org/download.php for the type of system your web server is running on.

Next place the XDebug binary you just downloaded into your PHP extensions directory depending on where you installed PHP for example C:\PHP\ext\.

Now you will need to open your php.ini file in your favorite text editor and add the following lines to the end of the file. These setting will later on help you in setting up tools such as Eclipse to work properly with XDebug on this server.

[xdebug]
xdebug.remote_enable=1
xdebug.remote_host=”localhost”
xdebug.remote_port=9000
xdebug.remote_handler=”dbgp”
zend_extension = C:\PHP\ext\php_xdebug-<replace with correct version>.dll

Restart your web server or PHP process to allow for these changes to take place and check your phpinfo() output to make sure XDebug set up properly.

Setting up XDebug under Microsoft Internet Information Services(IIS) 7 is quite simple and straight forward to do. The XDebug web site is a great help in finding the proper .dll for your environment as well as supplying you instructions on getting XDebug integrated properly into your particular PHP installation. To get started you will need to copy the phpinfo() output from your system and submit it using the form on the ”Tailored Installation Instructions” page. After submitting the form you will be supplied a link to download the proper XDebug .dll file for your set up and will also be presented with the instructions on what to do to enable XDebug within IIS 7. The instruction you receive from the form to enable XDebug will go something like this.

• Download php_xdebug-<replace with correct version>.dll
• Move the downloaded file to “C:\Program Files (x86)\PHP\v5.3\ext\
• Update C:\Program Files (x86)\PHP\v5.3\php.ini and change the line
  zend_extension = C:\Program\php_xdebug-<replace with correct version>.dll
• Restart the webserver

You may want to however instead of only adding the single line for XDebug to the bottom of your php.ini add the following lines which supplies further settings you may need when using XDebug in conjunction with an application such as Eclipse.

[xdebug]
xdebug.remote_enable=1
xdebug.remote_host=”localhost”
xdebug.remote_port=9000
xdebug.remote_handler=”dbgp”
zend_extension = C:\PHP\ext\php_xdebug-<replace with correct version>.dll

First we will need to add the IIS 7 feature to Windows by opening the Control Panel. Under “Programs and features” click on “Turn Windows Features on or off”. In the “Turn Windows features on or off” window click once on the “Internet Information Services” check box. This will select the default items needed to run IIS 7. Next expand “Internet Information Services” then expand “World Wide Web Services” then “Application Development Features”. You will then need to check the box next to “CGI” under this section in order to run PHP under FastCGI. At this time you may also with to reveiw the other features availble incase you need further support added into IIS 7 but for this post nothing else will need to be added. Once you have selected the wanted features and clicked “OK” you will have completed setting up IIS 7.

Once you have completed setting up IIS 7 you will now need to install PHP. In a windows environment I prefer to use the Microsoft Web Platform Installer which can be downloaded here to acomplish this task. After installing the Microsoft Web Platform Installer run the program. A nice tool for configuring PHP in an IIS 7 environment is a tool called PHP Manager for IIS. You can download this add in using the Microsoft Web Platform Installer by doing a seach within the application for “PHP manager”. Installing this addin will install PHP for you as well so you will not have to select PHP to install as well unless you wish to use an older version of PHP. Once setup has completed you are now ready to check on your install so far from within the Internet Information Services (IIS) Manager.

Open the Internet Information Services (IIS) Manager from within your administrative tools folder. Expand the sites list on the left and select the site entitled “Default Web Site”. In the middle of the window under “Default Web Site Home” under the IIS heading you should find an icon for “PHP Manager”. Double click the icon to open the PHP Manager. If the manager is showing any errors or more hen likely suggestions go ahead and apply or fix them. Generally the PHP Manager will do this for you it usually just entails check marking a box or two.

To check that PHP is running properly simply click on the link under PHP Setup entitled “Check phpinfo()”. This will display all current PHP information as well as setting for all your installed extensions.

If you wish to disable any existing extensions or enable more extensions This can be done using the link “Enable or disable an extension” found under the “PHP Extentions” heading. To enable or disable extension simply select the extension in question then enable or disable them. To add an extension clcik on “Add an extension” under the same hading and browse to the extensions .dll file.

That is it you now have IIS 7 running with PHP using FastCGI and a simple way to manage PHP frm within the Internet Information Services (IIS) Manager.

The site is running flawlessly using this configuration and the memory drain caused by Magento under Apache seems to be somewhat less then it used to be meaning I am no longer having to restart the Apache httpd service as I had in the past when things got gummed up be the resource hungry application know as Magento. This configuration takes into account you will want to run Magento under both http and https so the first thing you will want to do is make sure SSL support is enabled in your nginx.conf file.

    ##
    # SSL Support
    ##
 
    map $scheme $fastcgi_https {
    default off;
        https on;
    }

Now you will want to create your sites-available file (or virtual host file as it may be refered to) you will want to have the following text contained within this file named something like yourdomain.com. Make sure you replace your paths and domain name as well as the path to your SSL certificate file and key file with the appropriate information for your environment.

server {
    # Listen on port 80 as well as post 443 for SSL connections.
    listen 80;
    listen 443 default ssl;
 
    server_name yourdomain.com www.yourdomain.com;
 
    # Specify path to your SSL certificates.
    ssl_certificate /etc/nginx/certificates/yourcertificate.crt;
    ssl_certificate_key /etc/nginx/certificates/yourcertificate.key;
 
    # Path to the files in which you wish to
    # store your access and error logs.
    access_log /path/to/your/logs/access_log;
    error_log /path/to/your/logs/error_log;
 
    # If the site is accessed via yourdomain.com
    # automatically redirect to www.yourdomain.com.
    if ($host = 'yourdomain.com' ) {
        rewrite ^/(.*)$ http://www.yourdomain.com/$1permanent;
    }
 
    root /path/to/magento;
 
    location / {
        index index.html index.php;
        try_files $uri $uri/ @handler;
    }
 
    # Deny access to specific directories no one
    # in particular needs access to anyways.
    location /app/ { deny all; }
    location /includes/ { deny all; }
    location /lib/ { deny all; }
    location /media/downloadable/ { deny all; }
    location /pkginfo/ { deny all; }
    location /report/config.xml { deny all; }
    location /var/ { deny all; }
 
    # Allow only those who have a login name and password
    # to view the export folder. Refer to /etc/nginx/htpassword.
    location /var/export/ {
        auth_basic "Restricted";
        auth_basic_user_file htpasswd;
        autoindex on;
    }
 
    # Deny all attempts to access hidden files
    # such as .htaccess, .htpasswd, etc...
    location ~ /\. {
         deny all;
         access_log off;
         log_not_found off;
    }
 
    # This redirect is added so to use Magentos
    # common front handler when handling incoming URLs.
    location @handler {
        rewrite / /index.php;
    }
 
    # Forward paths such as /js/index.php/x.js
    # to their relevant handler.
    location ~ .php/ {
        rewrite ^(.*.php)/ $1 last;
    }
 
    # Handle the exectution of .php files.
    location ~ .php$ {
        if (!-e $request_filename) {
            rewrite / /index.php last;
        }
        expires off;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param HTTPS $fastcgi_https;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param MAGE_RUN_CODE default;
        fastcgi_param MAGE_RUN_TYPE store;
        include fastcgi_params;
    }
}

Save this file then create a symbolic link for this file in your site-available folder.

ln -s /path/to/nginx/sites-available/yourdomain.com /path/to/nginx/sites-enabled/yourdomain.com

Now restart nginx and your done. Be sure to test accessing the site via both http and https making sure when checking your https connection your SSL certificates are loading properly.

If you are using Visual Studio 2010 the easiest way to install the ASP.NET AJAX Control Toolkit is by using NuGet. If you are using Visual Studio 2008 you will need to follow the manual installation instructions further down this post. Of course if you are using Visual Studio 2010 you may also use the manual instructions as well if you wish.

Installing Using NuGet: (Visual Studio 2010)

Fist off you will need to make sure you have the NuGet Package Manager installed. If you do not have NuGet installed you can download it here. Once you have installed NuGet you have two choices as to how to install the ASP.NET AJAX Control Kit. You can install it via either the NuGet Package Manager Console or via the NuGet GUI.

To use the NuGet Package Manager Console start Visual Studio 2010. Once Visual Studio 2010 is opened open the solution in which you wish to use the toolkit. Now that you have your solution open click on ”Tools > Library Package Manager > Package Manager Console” at the top of Visual Studio 2010. This will open up the Package Management Console within Visual Studio 2010. Next at the Package Management Console command prompt, “PM>”, type the following and press enter.

PM> Install-Package AjaxControlToolkit

Once the Package Management Console command has completed the toolkit will have been successfully added and referenced within your solution and is ready to be used.

If you wish to use the NuGet GUI as before start Visual Studio 2010 and open the solution in which you wish to use the tookit. Click on “Tools > Library Package Manager > Manage NuGet Packages…” at the top of Visual Studio 2010. Once the GUI is openclick on the “Search Online” textbox at the top right hand corner and type “ajax” then hit the enter key. Look through the list of packages found in the center of the GUI for “AjaxControlToolkit, click on it then click “Install”. The toolkit will now have been added to and referenced within your solution and is ready to be used.

Installing Manually: (Visual Studio 2010 and Visual Studio 2008)

To install the ASP.NET Ajax Control Toolkit manually into either Visual Studio 2010 or Visual Studio 2008 you will fist need to download the latest version of the toolkit from the project download page which can be found here. You will find the binary downloads for both frameworks 3.5 and 4.0 are available. Download the one you wish to use and extract the files somewhere on your hard drive remebering the path to where you extracted the files.

Next you will need to add the toolkit to your toolbar within Visual Studio. To do so right click on an empty portion of your toolbar and click on “Add Tab”. This will add a new tab to your toobar. Next name the toolbar something like “ASP.NET AJAX Control Toolkit”. Next right click on your newly created tab and click on “Choose Items..”. Make sure the “.NET Framework Components” tab is selected then click on “Browse…”. Browse to where you extracted the toolkit files to earlier and open the file named “AjaxControlToolkit.dll” then click “OK”. You should now have available to you the ASP.NET AJAX Control Toolkit controls within your Toolbox.

As of late the news has been filled with stories of compromised web sites leaking personal data such as email addresses and passwords all over the Internet, some of the data even comes from multibillion dollar corporations such as in recent months Sony. To help protect yourself as well as any data stored on the Internet or locally on your network I have compiled this document regarding password policies mostly put together using the National Security Agency’s (NSA) recommendations on the matter.

A strong password should be at least 10 characters long and contain multiple character types including lowercase, uppercase, numbers and special characters as well as be difficult to guess. The reasoning behind this practice is to make your password as hard as possible to be revealed through someone making guesses or using software created to either brute force, attempt logins over and over with different passwords or show passwords which have been encrypted and stored within your computer or on a website whose data may have been compromised.

Login information including passwords should always be unique and never reused across multiple web sites or the same as the password used to log into your computer at work or home. This practice prevents someone who may have compromised a password on one system from gaining control of your accounts on other systems. Simply put, if login information is compromised on one site and it is the same login information used for your email account, Facebook, PayPal, Amazon.com or any other sites the chances of those accounts being compromised as well becomes highly likely and could result in serious consequences not limited to but including defamation of your name or even financial losses and identity theft. In the more recent releases of data from compromised sites most to the financial and personal damage has been a result of people gaining login information from one site and using this data to log into other sites such as PayPal and Facebook using the same login data.

Many sites make use of password recovery using a question and answer system. The answer to these questions should not be readily known by others nor be available through search engines such as Google and Bing or through public records stored on the Internet. When using systems utilizing this type of security it is best to provide false answers to these questions making sure these answers are unique across all systems just as with passwords yet something memorable to yourself. Keep in mind a mother’s maiden name is easily found through a simple search of public records and the High School you attended can be found by simply viewing your Facebook profile.

It is also a good practice to disallow programs such as web browsers from remembering and automatically entering login name and password data into a web sites login page. There are many programs available on the Internet to allow a malicious person who is able to gain direct access to your computer the ability to easily gain a list of this information stored in applications such as Internet Explorer or a Firefox plugin.

For more information on personal security on the Internet as well as learning more on how you can better secure your own personal network it is recommend that you take a look at the document from the National Security Agency entitle “Best Practices for Keeping Your Home Network Secure” which can be found at http://www.nsa.gov/ia/_files/factsheets/Best_Practices_Datasheets.pdf.This document not

It is recommended by the Chromium OS team that you use Ubuntu 10.04 when compiling Chromium OS which is the version I used when walking through the build myself. Also for this step by step walkthrough I am also running all commands unless specified starting from my user home directory.

The first step will be to download depot_tools. These tools are required for getting and syncing the current Chromium OS source code. The commands you will need to run to do so are as follows.

sudo apt-get install subversion
svn co http://src.chromium.org/svn/trunk/tools/depot_tools export PATH=${HOME}/depot_tools:"$PATH"

Next we will need to install Git. To do so run the following commands.

sudo apt-get install git-core gitk git-gui
git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Next we will need to make our source directory. Feel free to place this directory in a difrent location if you like but in order to more easily follow this walkthrough I suggest that if you do so you create a symbolic link to chromiumos in your home directory from where we are working from.

mkdir -p ${HOME}/chromiumos

Now it is time to get the latest source code. Run the following commands to allow connections to git and then using the depot tools we installed earlier get the latest version of the source code.

ssh -p 29418 gerrit.chromium.org
cd ${HOME}/chromiumos
repo init -u http://git.chromium.org/chromiumos/manifest.git
repo sync

We will now need to create a chroot inwhich we will do our work. The ./make_chroot command may take awhile to finish while it downloads compiles and moves around the tools needed to build Chromium OS.

cd src/scripts
./make_chroot
./enter_chroot.sh

After running ./enter_chroot.sh you should be at a command prompt which looks something like this.

(should see (cr) ((26d68ec...)) joe@ubuntu ~/trunk/src/scripts $)

Next we will need to initialize the build for a chosen board type. You will need to choose the board type depending on the processor type you are building Chromium OS for. Choose board type you wish to compile for and run ONE of the following two commands to store your chosen board type within your environment for referance through the rest of the build.

BOARD=x86-generic
BOARD=arm-generic

Now initialize the chosen board with the following command.

./setup_board --board=${BOARD}

It is now time to set the chronos password. The chronos account is the “root” or “sudo” access for the system and is the account you will need to log in with in order to get command line access to the system.

./set_shared_user_password.sh

It is now time to build the packages for the chosen board. The following command will download any needed files to build the packages, nearly 3GB on your first build as well as build any packages not available in binary form. This portion of the build may take awhile to complete depending on your connection and computer speed.

./build_packages --board=${BOARD} --oldchromebinary

Now we need to build the image by running the following command.

./build_image --board=${BOARD} --withdev --noenable_rootfs_verification

After the build has been completed it is now time to create our disk image. You have a few choices here either build a virtual machine image, bootable USB image or install directly to a Chrome OS notebook. I will not cover the installation to a Chrome OS notebook due to the fact I do not have one to test the steps out on.

To build a virtual machine image choose one of the following commands depending on the virtual machine environment you wish to run the image under. If you wish to create a USB image skip this step.

qemu

./image_to_vm.sh --board=${BOARD}

VMware

./image_to_vm.sh --board=${BOARD} --format=vmware

Virtualbox

./image_to_vm.sh --board=${BOARD} --format=virtualbox

To build a USB image you will run the following command.

./image_to_usb.sh --board=${BOARD}

You may specify a specific USB drive to send the image to by specifying the device it is running under such as /dev/sdc by adding the –to= flag followed by the location of the device as well.

./image_to_usb.sh --board=${BOARD} --to=/dev/sdc

You should now have a functioning virtual machine or bootable USB image of Chromium OS. Simply boot up your virtual machine using your chosen virtual machine software or boot directly to your USB drive if that was the type of medium you chose to run Chromium OS from.

The main difference between running WordPress on a server such as Apache is how the rewrites work. below is a working configuration which runs WordPress flawlessly using nginx which I use. This nginx site configuration file should reside in your /etc/nginx/sites-available/ folder. Be sure to change the paths within this configuration to reflect your paths to WordPress and log files. Once this configuration file is in place and linked to your sites-enabled folder restart your nginx process and you should be good to go with full support for WordPress’es Permalinks.

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
 
    # If the site is accessed via yourdomain.com
    # automatically redirect to www.yourdomain.com.
    if ($host = yourdomain.com' ) {
        rewrite  ^/(.*)$  http://www.yourdomain.com/$1  permanent;
    }
 
    access_log  /path/to/your/logs/access_log;
    error_log /path/to/your/logs/error_log;
 
    root   /path/to/wordpress;
    index  index.php index.html index.htm;
 
    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }
 
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }
 
    # Deny all attempts to access hidden files
    # such as .htaccess, .htpasswd, etc...
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
 
    # Begin WordPress specific items.
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
 
    rewrite /wp-admin/$ /wp-admin/index.php last;
    # End WordPress specific items.
 
    location ~ \.php$ {
        root   /path/to/wordpress;
 
        # Security against php processing files of
        # the same name but diffrent extentions.
        if (!-f $request_filename) {
            return 404;
        }
 
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include  fastcgi_params;
    }
}

There are a few solutions to FTP’s shortcomings when it comes to security such as FTPS and SFTP. In this post I will cover SSH File Transfer Protocol or SFTP. SFTP allows for secure file access, transfer and management over SSH which most Linux servers generally have installed to allow for remote administration.

By default any account with SSH access already has SFTP access as well. The problem with just adding a user and letting them have at it is that by default along with SFTP access users which you only wish to grant file management access also have shell access and may be able to install and run processes you may not wish them to run on your server. The following is a command by command walk through on how to allow users only file management access via SFTP while not allowing them to gain shell access on your server.

These command by command instructions are Ubuntu/Debian centric but only with the in the case of apt-get and process restart commands and should be no problem to adapt to any other distro. The first thing we will want to do is install SSH which generally is installed by default but just in case…

sudo apt-get install openssh-server

Once we know SSH is installed we can then begin to add users we wish to allow only SFTP access only to. We will start by adding a new user group to our system. I will use “sftponly” for the name of this group but the name of the group is up to you. Just be sure that if you use a different name to modify any proceeding referances to the “sftponly” group name with the one you used.

sudo groupadd sftponly

Now open the file /etc/ssh/sshd_config in your favorite text edit. I prefer nano for such trivial edits.

sudo nano /etc/ssh/sshd_config

Look for the line near the bottom of this file that looks like this.

Subsystem sftp /usr/lib/openssh/sftp-server

And change it to this.

Subsystem sftp internal-sftp

At the very bottom of this file you will need to add the following lines which restrict the “sftponly” user groups access when logging in via SSH.

# Rules for sftponly group
Match group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

Once you have added these lines save the file and restart the SSH process.

sudo /etc/init.d/ssh restart

Next we will create the home directory for the user we are about to add where they will be allowed file access to as well as where they will be chrooted or jailed. This directory can be located wherever but for the sake of this tutorial I will use the following directory.

sudo mkdir /var/www/vhost/domain.com/

Now we will need to add a user as we normally would under Linux. At this time we will also specify the users home directory which we just created using the “-d” flag. Remember to replace “sally” with the login name for the user you wish to add.

sudo useradd -d /var/www/vhosts/domain.com/ sally

Then we will need to change the group which the user we just added will belong to.

sudo usermod -g sftponly sally

Next we will set our new user’s shell to /bin/false which will not allowing our new user shell login.

sudo usermod -s /bin/false sally

We will now need to give ownership to any files and folders within the new users home directory which may exist such as folders brought over from a skel or created by an administrator setting up the users home directory manually.

sudo chown sally:sftponly -R /var/www/vhosts/domain.com/

Now comes an important part the newly created users home directory MUST be owned by root. If this directory is not owned by root then the newly created user may not be chooted or jailed within their home directory possibly allowing them access to other directories under theirs.

sudo chown root:root /var/www/vhosts/domain.com/

And that is it you now have set up a user allowed only SFTP access over SSH with no shell access and chroot them within their directory. You are now much safer then you were when running FTP.