Saturday, July 26, 2014

About SEPA Direct Debit payment system

Monday, July 14, 2014

Computer Network info.

DHCP message type
http://www.youtube.com/watch?v=0Dp7YoR0SLE

DHCPClient
 renew - date and time client should contact with its DHCP server to renew lease .
rebind - date and time client should contact with any DHCP  server to renew lease  .
expire - date and time client should release it lease

As tdescribed in  RFC 2131 DHCP is based on the Bootstrap Protocol and DHCP messages are implemented based on the messaged that were used by Bootstrap. This protocol uses the ports 67 and 68 for the server and client respectively. This is because at the time, these ports were not used by any other applications. The convention has been preserved by DHCP. So when the clients would want to receive the correct configuration they must used the port 68 as destination. SO if someone can block port 68 of client , they will never get ip.

Thursday, July 10, 2014

image scaling for retina display

http://bjango.com/articles/designingforretina2/

Designing for Retina display, part two

Answers to some of the most common questions I’ve been asked since writing the initial Retina display article andSmashing Magazine article.

Should my images be saved at a specific PPI?

No. iOS ignores PPI (pixels per inch) stored inside images. However, the pixel dimensions of your images do matter, so make sure you get those right. It’s also important to ensure your 2× images are exactly double the dimensions of your 1× images and that elements within the image are in the same positions — your Retina images should be identical content to their smaller counterparts, but with more detail.
Tech note: The PNG image format stores its pixel density as pixels per meter. This can cause rounding errors when converting between pixels per inch (PPI) and pixels per meter (PPM). Ever seen an image change from 300 to 299.999PPI when saved as a PNG? This is why.

Should my design document be a specific PPI?

July 2011 update: After a little bit of extra testing, I’ve reassessed my opinion on document PPI. I used to think it wasn’t too important, now I think it is, in certain specific situations.
Let’s say you have a document at 100PPI and another at 200PPI. If you use Copy Layer Style on a layer in the 100PPI document and Paste Layer Style on a layer in the 200PPI document, the Layer Style will be scaled. A 1px drop shadow would become a 2px drop shadow.
This sounds like a reasonable thing to do from Adobe’s perspective, but probably not what you’re after in most situations. Here’s why: If you’re being particular about your document PPI, you’re probably setting up your iPhone documents at 163PPI or 326PPI. Your iPad documents are probably set up at 132PPI (with 264PPI on the horizon).
If you’re working on an app that’s for both iPhone and iPad, there’s a strong chance you’ll copy elements and layer styles between your iPhone layout and iPad layout. If you have the document PPIs set to match the devices, your layer styles will get scaled by about 20% each time. That’s not an issue with 1px shadows, as they’ll be rounded up or down and likely stay the same, but any value larger than about 5px will be scaled.
My strong recommendation is to always set documents to 72PPI. I haven’t tested Fireworks or other design apps, but I suspect some may work the same way Photoshop does. It seems far safer to work at 72PPI, all the time.

Can’t I just design at 2× and bitmap scale down to 1×?

No. If you batch bitmap scale your images, or use Save for Web & Device’s image scaling or bitmap scale using any other method, you’ll be doing some serious damage to the quality of your 1× images. This is why everything should be built as vector objects with layer styles and other generated effects.
Take a look at the images below. The Bicubic and Nearest Neighbour versions have some significant quality loss, especially the text and near the top and right edge of the button. I realise that most text in your app will be generated by iOS, but the example still holds true — bitmap scaling hurts your images.

Do I really need to build two sets of images?

Yes. iOS needs a full set of 1× and 2× images. If iOS (or Xcode) bitmap scaled your 2× images down, the quality of your assets would be reduced. Please refer to the previous question for more detail.

Why build the initial design at 1×, rather than 2×?

There’s advantages to working on your design at 1×, but also advantages to working at 2×. Personal preference will play a big part in your decision. I favour building initially at 1×, then scaling up for the finishing touches and exporting. For me, the important factors are:

Pixel grid

Working at 1× ensures everything you do is locked to the 1× grid. Working at 2× means that you have to ensure you only use even positioning, even heights, even widths and even layer style values. If you don’t, uneven values (1, 3, 5 etc) will land on half pixels (0.5, 1.5, 2.5) when scaled down to 1×, resulting in blurry edges or rounding errors. If you choose to work at 2×, you’ll have to scale to 1× prior to exporting any images and double check everything’s ok.

Details

Working at 1× won’t allow you to see all the fine detail available on a Retina display, so you may forget to take advantage of it. You’ll also have to be careful when placing photographic elements if working at 1× — they’ll need to be converted to smart objects prior to shrinking them to the size they appear in the design.

Preview size

Working at 1× means a 1:1 pixel preview on your computer’s display will be smaller. In some cases this is vital, because your display may not be big enough to comfortably show a portrait iPhone Retina preview (960 pixels high, plus enough to fit the menubar, window bezels and dock). When the Retina display iPad is released, the situation will only get worse. I don’t know too many displays that can fit 2048 pixels vertically. The current 27” Cinema Display is 1440 pixels high, so even with the largest Apple display available, you won’t be able to work on portrait designs for a Retina iPad and see the entire iPad screen uncropped. Yep, a Retina iPad would have 3,145,728 pixels, just shy of a 27” Cinema Display’s 3,686,400 pixels. If you need to, take a moment to think about that.
Mike Rundle prefers starting at 2× and scaling down. I think it’s very likely that a lot of other designers would agree. Either is fine, provided your documents are built to scale up and down without losing quality — this will let you switch between 1× and 2× as you see fit throughout the process.
I thought it might be nice to hear from Mike why he prefers building at 2×.
“Starting a design at 2× from the start lets me get deep into the fine, pixel-level details immediately. Stuff like intricate textures and noise effects that will only be in the Retina graphics, not at the 1× size. I like to add detail at the 2× level that the 1× graphics won’t have, similar to a 512px icon on OS X compared to its 256px version. Always being on an even pixel and always applying Layer Style effects in even amounts is tricky, but it’s built into my mind now so I don’t think about it too much. It’s just a preference, everybody has their own way of doing it!”

Why not use Fireworks for UI design?

Fireworks is extremely capable, but I prefer Photoshop. In a lot of respects, the tools in Fireworks and Photoshop are similar or identical, so personal preference will likely be the deciding factor. I’ve been using Photoshop since version 2, so it’s very familiar. The times I have strayed and tried other apps, I haven’t liked them as much or missed vital features. For me, it’s as simple as that. However, I believe it’s important to present Fireworks as a good alternative, so here’s some words from Graham Clarke on why he uses Fireworks.
“I use Fireworks for all of my user interface work. Fireworks is a bit like the lovechild of Illustrator and Photoshop. It’s vectors… but with pixels in mind. And because of its web design heritage, exporting slices is pretty efficient in both workflow and compression quality. I just wish Adobe would take it a bit more seriously.”

Why not use Illustrator for UI design?

Illustrator is primarily vector-based. It lacks the pixel level control Photoshop and Fireworks have. It’s great for single elements though. If you’re building an app that predominately uses Apple’s UI elements, but you need some simple icons, Illustrator can be a good choice. If you need to build entire custom UIs with lots of elements, it’s simply not the way to go.

App icons are slightly different

Please note that the original Designing for Retina display article and this article discuss iOS app user interface design, not app icon design. App icons can be built in a similar way and a lot of the advice is the same, but have their own unique issues because they need to be scaled to a larger range of sizes.
If you have any questions, hit me up on Twitter and I’ll do my best to answer them.

Saturday, June 28, 2014

Firewall policies , rulesets, straetegy ,chains, iptables

Configure apache 2 using single ip for multiple https websites.

http://www.digicert.com/ssl-support/apache-multiple-ssl-certificates-using-sni.htm
https://www.digitalocean.com/community/tutorials/how-to-set-up-multiple-ssl-certificates-on-one-ip-with-apache-on-ubuntu-12-04

Steps 1: install apache2 using command  sudo apt-get install apache2

Steps 2: we should create different certificates for different https websites using openssl.Mainly three files are needed .
 SSLCertificateFile /path/to/www_yoursite_com.crt
 SSLCertificateKeyFile /path/to/www_yoursite_com.key
 SSLCertificateChainFile /path/to/DigiCertCA.crt

use openssl command to create it.
eg. openssl req -days 3650 -nodes -new -x509 -keyout ca.key -out ca.crt -config ./openssl.cnf
Steps 2:  follow steps provided in following link
https://www.digitalocean.com/community/tutorials/how-to-set-up-multiple-ssl-certificates-on-one-ip-with-apache-on-ubuntu-12-04

How To Set Up Multiple SSL Certificates on One IP with Apache on Ubuntu 12.04

You can host multiple SSL certificates on one IP Address using Server Name Indication (SNI).

About SNI

Although hosting several sites on a single virtual private server is not a challenge with the use of virtual hosts, providing separate SSL certificates for each site traditionally required separate IP addresses. The process has recently been simplified through the use of Server Name Indication (SNI), which sends a site visitor the certificate that matches the requested server name.

Note:

SNI can only be used for serving multiple SSL sites from your web server and is not likely to work at all on other daemons, such as mail servers, etc. There are also a small percentage of older web browsers that may still give certificate errors. Wikipedia has an updated list of software that does and does not support this TLS extension.

Set Up

SNI does need to have registered domain names in order to serve the certificates.
The steps in this tutorial require the user to have root privileges. You can see how to set that up in the Initial Server Setup Tutorial in steps 3 and 4.
Apache should already be installed and running on your VPS. If this is not the case, you can download it with this command:
sudo apt-get install apache2

Step One—Create Your SSL Certificates

For the purposes of this tutorial, both certificates will be self-signed. We will be working to create a server that hosts both example.com and example.org.
The SSL certificate has 2 parts main parts: the certificate itself and the public key. To make all of the relevant files easy to access, we should create a directory for each virtual host’s SSL certificate.
mkdir -p /etc/apache2/ssl/example.com
mkdir -p /etc/apache2/ssl/example.org

Step Two— Activate the SSL Module

The next step is to enable SSL on the droplet.
sudo a2enmod ssl
Follow up by restarting Apache.
sudo service apache2 restart

Step Three—Create a Self Signed SSL Certificate

When we request a new certificate, we can specify how long the certificate should remain valid by changing the 365 to the number of days we prefer. As it stands this certificate will expire after one year.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/example.com/apache.key –out /etc/apache2/ssl/example.com/apache.crt
With this command, we will be both creating the self-signed SSL certificate and the server key that protects it, and placing both of them into the new directory.
This command will prompt terminal to display a lists of fields that need to be filled in.
The most important line is "Common Name". Enter your official domain name here or, if you don't have one yet, your site's IP address.
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:NYC
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Awesome Inc
Organizational Unit Name (eg, section) []:Dept of Merriment
Common Name (e.g. server FQDN or YOUR name) []:example.com                  
Email Address []:webmaster@awesomeinc.com
Then go ahead and take the same steps for the second (example.org) domain:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/example.org/apache.key -out /etc/apache2/ssl/example.org/apache.crt

Step Four—Create the Virtual Hosts

Once you have the certificates saved and ready, you can add in your information in the virtual host files.
Although it’s not required, we can create two virtual host files to store virtual host information in separate files, copying the configuration from the default virtual host file.
sudo nano /etc/apache2/sites-available/example.com
sudo nano /etc/apache2/sites-available/example.org
Go ahead and open up each file and paste in the configuration below. This configuration is a simplified version of two separate configuration files: the default virtual server configuration file found at /etc/apache2/sites-available/default and the default SSL configuration located in /etc/apache2/sites-available/default-ssl.
Additionally, this configuration includes an important change that facilitates multiple SSL certificates. Whereas the default SSL configuration has the following line, specifying a certificate as the default one for the server,
<VirtualHost _default_:443>
the configuration below does not have a reference to a default certificate. This is key.
Overall, the default configuration files offer a variety of useful directives and additional configuration options that you can add to the virtual host. However, the following information will provide the server everything it needs to set up multiple SSL certificates on one IP address.
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName example.com
        DocumentRoot /var/www

</VirtualHost>


<IfModule mod_ssl.c>
<VirtualHost *:443>

        ServerAdmin webmaster@localhost
        ServerName example.com
        DocumentRoot /var/www

        #   SSL Engine Switch:
        #   Enable/Disable SSL for this virtual host.
        SSLEngine on

        #   A self-signed (snakeoil) certificate can be created by installing
        #   the ssl-cert package. See
        #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
        #   If both key and certificate are stored in the same file, only the
        #   SSLCertificateFile directive is needed.
        SSLCertificateFile /etc/apache2/ssl/example.com/apache.crt
        SSLCertificateKeyFile /etc/apache2/ssl/example.com/apache.key
</VirtualHost>

</IfModule>
There are a few lines in these configuration files that need to be customized.
  • ServerAdmin: This is simply your webmaster’s email address
  • ServerName: This is your domain name. Make sure that you write it in without a prepended www.
  • DocumentRoot: This is the directory where you keep your site information. Currently it points to the apache default directory. You will probably have different server roots for the 2 different virtual hosts.
  • SSLCertificateFile: This directive points to the location of the certificate file. The certificate for each site is stored in the directory that we created earlier in the tutorial.
  • SSLCertificateKeyFile : This directive points to the location of the certificate key. The certificate key for each site is stored in the directory that we created earlier in the tutorial.
Set up both domains’ configurations. We still have more step before the separate SSL certificates will work on both servers.

Step Five—Edit the ports.conf file

The final step required to make sure that multiple certificates work on one VPS is to tell the server to listen on port 443. Add the bolded line to the apache ports configuration file.
sudo nano /etc/apache2/ports.conf 
NameVirtualHost *:80
NameVirtualHost *:443

Listen 80

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to 
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Step Six—Activate the Virtual Hosts

The last step is to activate the hosts. Apache makes activating and deactivating hosts very easy.
sudo a2ensite example.com
sudo a2ensite example.org
(You can deactivate virtual hosts with the command: sudo a2dissite example.com)
With all of the virtual hosts in enabled, restart apache.
sudo service apache2 restart
You should now be able to access both sites, each with its own domain name and SSL certificate.
You can view the sites both with and without the signed SSL certificates by typing in just the domain (eg. example.com or example.org) or the domain with the https prefix (https://example.com or https://example.org).