Sunday, July 12, 2015
Speed test from CMD
# wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
# chmod +x speedtest-cli
# ./speedtest-cli
if pip does not work but is installed like here:
root@ubuntu12:~# pip -v
-bash: /usr/bin/pip: No such file or directory
root@ubuntu12:~# which pip
/usr/local/bin/pip
root@ubuntu12:~# pip
-bash: /usr/bin/pip: No such file or directory
root@ubuntu12:~# type pip
pip is hashed (/usr/bin/pip)
Just run: # hash -r
root@ubuntu12:~# hash -r
root@ubuntu12:~# pip
Usage:
pip <command> [options]
Commands:
install Install packages.
uninstall Uninstall packages.
freeze Output installed packages in requirements format.
list List installed packages.
show Show information about installed packages.
search Search PyPI for packages.
wheel Build wheels from your requirements.
help Show help for commands.
General Options:
-h, --help Show help.
--isolated Run pip in an isolated mode, ignoring environment variables and user configuration.
-v, --verbose Give more output. Option is additive, and can be used up to 3 times.
-V, --version Show version and exit.
-q, --quiet Give less output.
--log <path> Path to a verbose appending log.
--proxy <proxy> Specify a proxy in the form [user:passwd@]proxy.server:port.
--retries <retries> Maximum number of retries each connection should attempt (default 5 times).
--timeout <sec> Set the socket timeout (default 15 seconds).
--exists-action <action> Default action when a path already exists: (s)witch, (i)gnore, (w)ipe, (b)ackup.
--trusted-host <hostname> Mark this host as trusted, even though it does not have valid or any HTTPS.
--cert <path> Path to alternate CA bundle.
--client-cert <path> Path to SSL client certificate, a single file containing the private key and the certificate in PEM format.
--cache-dir <dir> Store the cache data in <dir>.
--no-cache-dir Disable the cache.
--disable-pip-version-check
Don't periodically check PyPI to determine whether a new version of pip is available for download. Implied with --no-index.
root@ubuntu12:~#
Tuesday, July 7, 2015
Install & configure OpenVPN
#files:
lzo-2.06-1.el6.rfx.x86_64.rpm (http://pkgs.repoforge.org/lzo/lzo-2.06-1.el6.rfx.x86_64.rpm)
pkcs11-helper-1.10.tar.bz2 ()
if you are running on centos5 try this file: http://pkgs.repoforge.org/lzo/lzo-minilzo-2.06-1.el5.rf.x86_64.rpm
#dependencies:
#run:
rpm -ivh /tmp/lzo-2.06-1.el6.rfx.x86_64.rpm
#run
rpmbuild -tb /tmp/pkcs11-helper-1.10.tar.bz2
#run:(if this doesnt work search for pkcs11-helper like this: find / -name 'pkcs11-helper*' )
rpm -ivh /root/rpmbuild/RPMS/x86_64/pkcs11-helper-1.10-2.x86_64.rpm /root/rpmbuild/RPMS/x86_64/pkcs11-helper-devel-1.10-2.x86_64.rpm
#run:
rpm -ivh /tmp/openvpn-2.1.4-2.el6.rf.x86_64.rpm
Configuring openvpn
# cd /usr/share/doc/openvpn-2.0.9
# cp -av easy-rsa /etc/openvpn/
# cd /etc/openvpn/easy-rsa/
# vim vars
In the vars file, edit the KEY_* entries at the bottom of the file, such as KEY_COUNTRY, KEY_ORG, KEY_EMAIL, etc. These will be used to build the OpenSSL certificates. Next, it’s time to initialize the PKI:
# . ./vars
# sh clean-all
# sh build-ca
# sh build-key-server server
For the above, and the below client certificates, you can enter pretty much anything for the “Common Name” field, however there is a certain logic to use: “OpenVPN-CA” when generating the Certificate Authority, “server” when generating the server certificate, and “client” or the name of the specific client system for the client certificates. Those certificates are generated with:
# sh build-key client1
# sh build-key client2
The next step is to generate the Diffie Hellman parameters for the server:
# sh build-dh
When this is done, you will have a number of files in the keys/ subdirectory. At this point, for the clients, you want to copy the appropriate files to them securely (i.e., via SSH or on a USB stick); the files the clients need are ca.crt, client1.crt, and client1.key (or whatever you named the files when you generated them with the build-key script).
Next, create the OpenVPN server configuration file. To get up and running quickly, copy one of the example config files:
# cd /etc/openvpn/
# cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf .
# vim server.conf
The aim here is to get this going right away, so we won’t examine each of the options in detail. The primary things you want to do are to uncomment the “user” and “group” directives, to make the openvpn process run as the unprivileged “nobody” user. You may also want to change the “local” directive to make it listen to one specific IP address. This would be the IP to which your firewall is forwarding UDP port 1194. As well, you will want to set the “client-to-client” directive to enable it, and also set the “push” directives for route and DNS options. What follows is a comment-stripped server.conf, as an example:
local 192.168.10.11
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.10.0 255.255.254.0"
push "dhcp-option DNS 192.168.10.12"
push "dhcp-option DOMAIN domain.com"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
Finally, copy the required keys and certificates that you previously generated:
# cd /etc/openvpn/
# cp easy-rsa/keys/ca.crt .
# cp easy-rsa/keys/server.{key,crt} .
# cp easy-rsa/keys/dh1024.pem .
And, finally, start the OpenVPN server:
# /etc/init.d/openvpn start
To get routing set up properly on the server so that remote clients, when they connect, can reach more than just the server itself, you will need to enable IP forwarding. This can be done by the following:
# echo 1 > /proc/sys/net/ipv4/ip_forward
You can also do it by editing /etc/sysctl.conf and adding the following (this is a good thing to do as it will ensure that packet-forwarding persists across reboots):
net.ipv4.ip_forward = 1
You also want to ensure that packets going back to the client system are routed properly. This can be done by changing the route on the gateway of the server’s network to route packets to the client network (10.8.0.1/32) through the OpenVPN server (if the server happens to be the gateway as well, you don’t have to do anything additional to accomplish this). How this is done largely depends on the operating system of the gateway.
Once this is done, you should be able to ping any machine on the server’s LAN from the client, and be able to ping the client from any machine on the server’s LAN. For instance, from a machine on the server LAN (not the server):
% traceroute 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 64 hops max, 52 byte packets
1 fw (192.168.10.1) 0.848 ms 0.342 ms 0.249 ms
2 server (192.168.10.11) 0.214 ms 0.231 ms 0.243 ms
3 server (192.168.10.11) 0.199 ms !Z 0.443 ms !Z 0.396 ms !Z
% ping 10.8.0.6
PING 10.8.0.6 (10.8.0.6): 56 data bytes
64 bytes from 10.8.0.6: icmp_seq=0 ttl=63 time=17.540 ms
And from the client:
# traceroute 192.168.10.65
traceroute to 192.168.10.65 (192.168.10.65), 30 hops max, 40 byte packets
1 10.8.0.1 (10.8.0.1) 22.963 ms 27.311 ms 27.317 ms
2 10.8.0.1 (10.8.0.1) 27.297 ms !X 27.294 ms !X 27.269 ms !X
# ping 192.168.10.65
PING 192.168.10.65 (192.168.10.65) 56(84) bytes of data.
64 bytes from 192.168.10.65: icmp_seq=1 ttl=62 time=515 ms
The setting up of OpenVPN clients will be the subject of two tips in the next week. I’ve made the assumption that the client is correctly configured here, simply to illustrate how it should look when it all works together, but in the next parts of this series we will get into more depth with the client configuration.
Download the PDF, “How to set up OpenVPN server and create Linux and Mac OS X clients.“
Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.
lzo-2.06-1.el6.rfx.x86_64.rpm (http://pkgs.repoforge.org/lzo/lzo-2.06-1.el6.rfx.x86_64.rpm)
pkcs11-helper-1.10.tar.bz2 ()
if you are running on centos5 try this file: http://pkgs.repoforge.org/lzo/lzo-minilzo-2.06-1.el5.rf.x86_64.rpm
#dependencies:
#run:
rpm -ivh /tmp/lzo-2.06-1.el6.rfx.x86_64.rpm
#run
rpmbuild -tb /tmp/pkcs11-helper-1.10.tar.bz2
#run:(if this doesnt work search for pkcs11-helper like this: find / -name 'pkcs11-helper*' )
rpm -ivh /root/rpmbuild/RPMS/x86_64/pkcs11-helper-1.10-2.x86_64.rpm /root/rpmbuild/RPMS/x86_64/pkcs11-helper-devel-1.10-2.x86_64.rpm
#run:
rpm -ivh /tmp/openvpn-2.1.4-2.el6.rf.x86_64.rpm
Configuring openvpn
# cd /usr/share/doc/openvpn-2.0.9
# cp -av easy-rsa /etc/openvpn/
# cd /etc/openvpn/easy-rsa/
# vim vars
In the vars file, edit the KEY_* entries at the bottom of the file, such as KEY_COUNTRY, KEY_ORG, KEY_EMAIL, etc. These will be used to build the OpenSSL certificates. Next, it’s time to initialize the PKI:
# . ./vars
# sh clean-all
# sh build-ca
# sh build-key-server server
For the above, and the below client certificates, you can enter pretty much anything for the “Common Name” field, however there is a certain logic to use: “OpenVPN-CA” when generating the Certificate Authority, “server” when generating the server certificate, and “client” or the name of the specific client system for the client certificates. Those certificates are generated with:
# sh build-key client1
# sh build-key client2
The next step is to generate the Diffie Hellman parameters for the server:
# sh build-dh
When this is done, you will have a number of files in the keys/ subdirectory. At this point, for the clients, you want to copy the appropriate files to them securely (i.e., via SSH or on a USB stick); the files the clients need are ca.crt, client1.crt, and client1.key (or whatever you named the files when you generated them with the build-key script).
Next, create the OpenVPN server configuration file. To get up and running quickly, copy one of the example config files:
# cd /etc/openvpn/
# cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf .
# vim server.conf
The aim here is to get this going right away, so we won’t examine each of the options in detail. The primary things you want to do are to uncomment the “user” and “group” directives, to make the openvpn process run as the unprivileged “nobody” user. You may also want to change the “local” directive to make it listen to one specific IP address. This would be the IP to which your firewall is forwarding UDP port 1194. As well, you will want to set the “client-to-client” directive to enable it, and also set the “push” directives for route and DNS options. What follows is a comment-stripped server.conf, as an example:
local 192.168.10.11
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.10.0 255.255.254.0"
push "dhcp-option DNS 192.168.10.12"
push "dhcp-option DOMAIN domain.com"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
Finally, copy the required keys and certificates that you previously generated:
# cd /etc/openvpn/
# cp easy-rsa/keys/ca.crt .
# cp easy-rsa/keys/server.{key,crt} .
# cp easy-rsa/keys/dh1024.pem .
And, finally, start the OpenVPN server:
# /etc/init.d/openvpn start
To get routing set up properly on the server so that remote clients, when they connect, can reach more than just the server itself, you will need to enable IP forwarding. This can be done by the following:
# echo 1 > /proc/sys/net/ipv4/ip_forward
You can also do it by editing /etc/sysctl.conf and adding the following (this is a good thing to do as it will ensure that packet-forwarding persists across reboots):
net.ipv4.ip_forward = 1
You also want to ensure that packets going back to the client system are routed properly. This can be done by changing the route on the gateway of the server’s network to route packets to the client network (10.8.0.1/32) through the OpenVPN server (if the server happens to be the gateway as well, you don’t have to do anything additional to accomplish this). How this is done largely depends on the operating system of the gateway.
Once this is done, you should be able to ping any machine on the server’s LAN from the client, and be able to ping the client from any machine on the server’s LAN. For instance, from a machine on the server LAN (not the server):
% traceroute 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 64 hops max, 52 byte packets
1 fw (192.168.10.1) 0.848 ms 0.342 ms 0.249 ms
2 server (192.168.10.11) 0.214 ms 0.231 ms 0.243 ms
3 server (192.168.10.11) 0.199 ms !Z 0.443 ms !Z 0.396 ms !Z
% ping 10.8.0.6
PING 10.8.0.6 (10.8.0.6): 56 data bytes
64 bytes from 10.8.0.6: icmp_seq=0 ttl=63 time=17.540 ms
And from the client:
# traceroute 192.168.10.65
traceroute to 192.168.10.65 (192.168.10.65), 30 hops max, 40 byte packets
1 10.8.0.1 (10.8.0.1) 22.963 ms 27.311 ms 27.317 ms
2 10.8.0.1 (10.8.0.1) 27.297 ms !X 27.294 ms !X 27.269 ms !X
# ping 192.168.10.65
PING 192.168.10.65 (192.168.10.65) 56(84) bytes of data.
64 bytes from 192.168.10.65: icmp_seq=1 ttl=62 time=515 ms
The setting up of OpenVPN clients will be the subject of two tips in the next week. I’ve made the assumption that the client is correctly configured here, simply to illustrate how it should look when it all works together, but in the next parts of this series we will get into more depth with the client configuration.
Download the PDF, “How to set up OpenVPN server and create Linux and Mac OS X clients.“
Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.
Subscribe to:
Posts (Atom)