Just the Privacy and Security part

from ipduh privacy and the https search fix

Many computer users think that by installing and using some browser plugin they will magically protect their privacy --which is false.

Every time you install a browser-plugin you run yet more brilliant xor stupid and good xor evil code that expands the attack surface on your system and your privacy and adds features or bugs or backdoors.

Actually, privacy-wise disabling javascript is OK, installing random plugins that run tones of "obfuscated" javascript or compiled closed code that you have no clue of what it really does in your browser is usually not. Plugins like flash, java, quicktime, itunes, silverlight, adobe reader, windows media player may be more dangerous for your privacy or your security than javascript plugins.

In addition, every time that you do not look like an average human using an average system you stick out and many of your plugins are visible if you are running javascript.

In most modern web browsers you do not need special browser plugins in order to disable cookies or javascript. Try it out. You will soon realize that most of the web is broken without javascript even though ipduh is not very broken.

When it comes to modern web browsers I consider Chrome and Mozilla based browsers put together by companies or groups I "trust" (Google, Mozilla, Debian) more secure than Microsoft Internet Explorer and Opera and IE and Opera more secure than the rest ...
don't ask me for a formal proof ... it is an opinion ...

However, Chromium and Mozilla based browsers ( Chrome , Firefox , Seamonkey , Iceweasel etc ) , Safari , Internet Explorer , Opera and the rest of the modern web browsers are ridiculously complex pieces of software used by millions if not billions of humans. There you have both opportunity and motivation for profit, control and power. Hence, all modern browsers are insecure. Put together or read thoroughly the source of a basic text HTTP(s) client if you are really paranoid.

Certain three letter agencies may have exploits or backdoors that compromise your browser and your privacy ( accessing your system ,even gaining administrator privileges, and certainly seeing 'your' first public IP address ) even if you do not run javascript or plugins. And they may be able to do that without even having you visiting a website they (p)own. Connecting to the Internet and firing up your web browser may be enough.

Up untill recently I had a little 'java applet' that would reveal your private and your first public IP address in the anonymity checker. If an one man weekend software shop can do this, imagine what larger software shops, the software shops that put together your web browser or government agencies can do.

Unfortunately many incompetent or devious folks are in the business of talking privacy or selling privacy. If you are concerned about your privacy you should take the matter in your hands and not leave it to me or anyone else. Use a common up-to-date browser put together by someone you 'trust' that does not stick out and use a combination of privacy tools like Tor or some sort of VPN which is used by many users and not just you.

A VPN, a proxy or an intermediate 'dark net' like Tor or I2P may harm your system or compromise even more your privacy if it is misused by you or purposely configured by its operators to do so.

Combine and alternate privacy tools and test settings and tools in many ways. An easy privacy test is the ipduh anonymity checker.























Just the Privacy and Security part



















added the MAC address to vendor tool to apropos



A while ago I put together a little tool
that maps EUI-48 and EUI-64 Media Access Control ( MAC ) addresses to Vendors
eg 00:00:0C:DE:FE:DC



I just added it to apropos
and it works with : and - delimiters
eg 00:00:08:02:11:B0 or 00:00:08:02:11:a0



MAC to Vendor from apropos

ipduh privacy and the https search fix





If apropos gets a query not related to inter-networking technology stuff like ip , dns , etc
sends it to a custom google

The ipduh custom google search is using google APIs and javascript pulled from google.
By mistake the google javascript URI was using always HTTP even when someone was using ipduh over HTTPS --my bad. I am sorry.

Due to my mistake, javascript run by your browser and some ipduh queries were traveling the internets in plaintext even when you were visiting ipduh over HTTPS. My mistake is fixed now and the google javascript is being always downloaded from a TLS encrypted URL.

If you are concerned about your privacy you should at least visit ipduh over HTTPS.
It is safe to trust and install the ipduh Certificate Authority if you trust me. I am certainly less evil and more skilled than many managers of CAs installed in your browser or your OS by default.

However,there is not an established trust path to ipduh and someone in between you and an ipduh server may serve you another ipduh server cerificate or CA certificate the very first time.

If you want to be sure that you installed the original ipduh CA certificate verify the certificate's fingerprint at https://github.com/ipduh/ipduhca.
My github CA repository provides only a way to verify the certificate fingerprint through an established trust path and has nothing to do with my TLS.

Provided that you trust me and that you installed the original ipduh server certificate or CA certificate in your browser, the authentication of ipduh and the encryption between ipduh and you is the same with the authentication and encryption provided by keys signed by Certificate Authorities like Comodo, Thawte etc.
Authenticating the ipduh servers is just a little tougher the very first time.

Many computer users think that by installing and using this or the other browser plugin they will protect their privacy --which is false.
Every time you install a browser-plugin you run yet more brilliant xor stupid and good xor evil code that expands the attack surface on your system and your privacy and adds features or bugs or backdoors.
Actually, privacy-wise disabling javascript is OK, installing random plugins that run tones of "obfuscated" javascript or compiled closed code that you have no clue of what it really does in your browser is usually not.
Also, every time that you do not look like an average human using an average system you stick out and many of your plugins are visible if you are running javascript.

You may disable cookies and even javascript for ipduh. This way you will evade some of the ipduh analytics and the google ads and still get a somewhat usable site. ( ipduh analytics have absolutely nothing to do with google analytics )
I do my best to provide a service that does not depend on javascript and I tried from the beginning to accommodate scripts and automated tools provided they do not abuse my service.

At least in Mozilla based browsers you do not need special browser plugins in order to disable cookies or javascript. Try it out. You will soon realize that most of the web is broken.

Plugins like flash, java, quicktime, itunes, silverlight, adobe reader, windows media player may be more dangerous than javascript plugins.

When it comes to modern web browsers I consider Chrome and Mozilla based browsers put together by companies or groups I "trust" (Google,Mozilla,Debian) much more secure than Opera, Microsoft Internet Explorer and the rest. However, Chrome and Mozilla based browsers ( Firefox , Seamonkey , Iceweasel etc ) are ridiculously complex pieces of software used by millions if not billions of humans. There you have both opportunity and motivation for profit, control, power. Hence, all modern browsers are insecure. Put together a basic text HTTP(s) client if you are really paranoid.

Certain three letter agencies may have exploits or backdoors that compromise your browser and your privacy ( accessing your system ,even gaining administrator privileges, and certainly seeing 'your' first public IP address ) even if you do not run javascript or plugins.

Back to logging at ipduh.
Most ipduh usage analytics are based on connection logs from layer 3 up to HTTP(S). I am not using google analytics or any other third party web analytics service.
( I am using google analytics at alog though :) )
At ipduh I am the only one who looks at logs and only when something bad happens.

Many incompetent or devious folks are in the business of talking privacy or selling privacy. If you are concerned about your privacy you should take the matter in your hands and not leave to me or anyone else. Use a common up-to-date browser put together by someone you 'trust' that does not stick out and use a combination of privacy tools like Tor or some sort of VPN which is used by many users and not just you.

A VPN, a proxy or an intermediate 'dark net' like Tor or I2P may harm your system or compromise even more your privacy if it is misused by you or purposely configured by its operators to do so.

Combine and alternate privacy tools and test settings and tools in many ways. An easy privacy test is the ipduh anonymity checker.







ipduh https search fix and privacy stuff ...







Greek ISPs Caching DNS









A list with DNS servers provided by the Greek Internet Service Providers.

sl.ipduh.com/gr-isp-dns

gr-isp-dns (the actual ipduh-list URI)



Most caching name servers operated by Greek ISPs answer only to DNS queries coming from their own networks. You will need to use Public DNS Caches or your own recursive-resolver if you need caching DNS that works everywhere.











Nameservers-DNS for Greek ISPs

samba ... mount windows shares from windows

mount windows shares on windows
net use \\192.168.1.2\share password /USER:sambauser







unmount all samba filesystems

Unmount all cifs ( samba ) shares.
# umount -a -t cifs -l






unount samba shares



GLBer

GLBer Notes



GLBer Creates the RouterOS configuration commands and a RouterOS script for the g0 Load BalanER aka GLBer. Then the Mikrotik RouterOS Router with the multiple point-to-point or point-to-multipoint uplinks balances the traffic among all uplinks without using source based policy routing.



You need to copy the configuration commands and the RouterOS script that GLBer produces from a host that has bash to the RouterOS router e.g. from a bash shell in a Terminal to a winbox terminal in the RouterOS.



RouterOS flushes the routing table every 10 minutes and then there is a good chance to reset the masqueraded connections. The RouterOS script created by GLBer runs every 10 minutes and resets the equal cost multipath route raising more the chance for the masqueraded connections to reset in a 10 minutes period.



Install GLBer
# wget https://raw.githubusercontent.com/ipduh/glber/master/glber -O /usr/bin/glber && chmod 755 /usr/bin/glber




Create the RouterOS GLBer Configuration For 3 point-to-point uplinks
$ glber 

GLBer, g0 2014
Quick How-To: http://sl.ipduh.com/glber

Enter gateways: alfa beta gama
Enter interfaces: 

If all the uplink interfaces are point-to-point just enter their names when asked for gateways and just hit enter when glber asks you for interfaces.



Create the RouterOS GLBer configuration for 4 point-to-point uplinks and an uplink available in the LAN through the router's eth5 interface.
$ glber 

GLBer, g0 2014
Quick How-To: http://sl.ipduh.com/glber

Enter gateways: 10.21.241.101 alfa beta gama delta
Enter interfaces: eth5 alfa beta gama delta





GLBer logs all runs in ~/glber/UTC-UNIX-EPOCH.log

To Clean a RouterOS from the GLBer configuration find the UTC-UNIX-EPOCH in the RouterOS created by GLBer e.g. for the epoch 1420624338 you would run
$ glber file ~/glber/1420624338.log
and run the GLBer RouterOS commands under
###RouterOS commands to remove the GLBer configuration###
in the RouterOS terminal.











old glber



glber

Virtualbox or VMware vmdk to KVM qcow2

Migrate Virtualbox or VMware guest (on vmdk) to KVM




See disk image information.
# qemu-img info lwa-flat.vmdk 
image: lwa-flat.vmdk
file format: raw
virtual size: 50G (53687091200 bytes)
disk size: 50G




Convert the vmdk image to a qcow2 image.
# qemu-img convert -O qcow2 lwa-flat.vmdk lwa-flat.qcow2




Create a guest definition and start guest.
# virt-install --connect qemu:///system --import -n lwa \
--vcpus=1 --ram=2048 \
--disk path=/home/vm/fromvbox/lwa-flat.qcow2,device=disk,format=qcow2 \
--vnc --noautoconsole --os-type linux --description lwa \
--network=bridge:b0 --hvm




Migrate VMware or Virtualbox vmdk to KVM qcow2



ipduh v3

Finally! done "upgrading" ipduh to v3 ...


Some of the most noticeable changes-improvements are:










ipduh v3



dovecot imap over ssl in debian notes

IMAP over SSL with dovecot in debian

Install the Dovecot IMAP deamon
# apt-get install dovecot-imapd


For a quick (& perhaps sloppy) debian setup just append the following to /etc/dovecot/dovecot.conf
listen = 192.0.2.1
syslog_facility = mail
mail_location = maildir:~/Maildir
ssl = yes
ssl_cert = </etc/ssl/certs/imap.signed.crt
ssl_key = </etc/ssl/private/imap.private.pem
ssl_verify_client_cert = no
protocol imap {
  imap_client_workarounds = tb-extra-mailbox-sep
}
auth_mechanisms = plain login


The IMAP daemon listens at 192.0.2.1
and Maildir mailboxes are used by the Mail system.
The imap_client_workarounds definition is used to work around Thunderbird peculiarities and the auth_mechanisms definition to add login --work around Outlook pecularities.

For a cleaner configuration file you may do the following.
# cd /etc/dovecot
# stor dovecot.conf
# doveconf -n > dovecot.conf


Restart the imap daemon
# /etc/init.d/dovecot restart


However, it seems like it speaks up to SSLv3 and not TLS at all.



dovecot SSL IMAP



Trust the ipduh CA certificate in debian





Trust the ipduh CA certificate in debian.
# wget https://raw.githubusercontent.com/ipduh/ipduhca/master/ipduhca.crt -O /usr/local/share/ca-certificates/ipduhca.crt
# update-ca-certificates




Trust the ipduh CA



clone a KVM guest





"Clone" a KVM debian guest notes.



Shutdown or Suspend the host.



Create a clone of the host democritos.
# virt-clone -o democritos -n thales -f /home/vm/thales.qcow2 -d
...
Clone 'thales' created successfully.
...
The clone disk is at /home/vm/thales.qcow2

This is good enough if we just need a clone with a different MAC Address and a different UUID. However, if we need a host that can work simultaneously with the original host we (most likely) need a bit more variation.



Log in to the clone or mount it's image to change hostname, IP address(es), etc.



Change Hostname.
# cd /etc
# grep -ril `hostname -f` |tee hostname.file.list
apache2/sites-available/000.dup.ipduh.awmn.conf
postfix/main.cf
hostname
hosts
mailname
ssh/ssh_host_ecdsa_key.pub
ssh/ssh_host_rsa_key.pub
ssh/ssh_host_dsa_key.pub
aliases.db
# perl -i.0 -p -e 's/demokritos/thales/g;' `cat hostname.file.list`




Change IP address.
# grep -ril '192.0.2.61' /etc |tee ip.file.list
/etc/network/interfaces
/etc/hosts
# perl -i.old_ip -p -e 's/192.0.2.61/192.0.2.62/g;' `cat ip.file.list`




Reboot Clone
# shutdown -r now




Log in to thales ( the cloned system )



Create a new RSA ssh key
# ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
Generating public/private rsa key pair.
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
a6:fc:76:OF:F1:33:7C:04:77:07:ce:5a:cf:23:48:3a root@thales
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|             .   |
|            . .  |
|        S  . ----|
|     . o   .=  o.|
|      +   o..o..=|
|       ..E....o++|
|       ....  o=++|
+-----------------+




Overwrite the DSA SSH key with a new one.
# ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa




Overwrite the ECDSA SSH key with a new with the largest (practical) key-size (allowed).
# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa -b 521




In a debian based system you may use dpkg to replace the SSH keys
# dpkg-reconfigure openssh-server














clone a KVM guest



move kvm guest notes

Move (not live migration) a KVM VM from a host B to a host C.

Assuming that the guest VM is bridged and that both KVM hosts are in the same ethernet segment.

Shutdown guest VM.

Copy guest VM image from host B to host C.
b# scp /vm/vm2.qcow2 root@c:/vm


Dump XML definition and copy it to the destination host.
b# virsh dumpxml vm2 > vm2.xml
b# scp vm2.xml root@c:/etc/libvirt/qemu


On host C (the destination host) define the quest xml definition.
c# virsh define /etc/libvirt/qemu/vm2.xml
Domain vm2 defined from /etc/libvirt/qemu/vm2.xml


Start VM guest on the destination system.
c# virsh start vm2
Domain vm2 started


Disable autostart for the VM guest in B (the original host).
b# virsh autostart vm2 --disable
Domain vm2 unmarked as autostarted


Enable autostart for the moved VM guest in C (the destination host).
c# virsh autostart vm2
Domain vm2 marked as autostarted






Move KVM guest to another Host



install debian-packaged awstats





Notes on installing and using debian-packaged AWStats to analyze Apache logs.



Install debian packaged awstats ( now v7.0 )
# apt-get install awstats




I would use the following setup in apache2 installations with site(s) or virtual host(s) that belong to the same person-organization and I would NOT use it in a shared hosting environment.



Get the apache configuration file.
# wget https://raw.githubusercontent.com/ipduh/apache2_awstats_conf/master/awstats.conf -O /etc/apache2/conf.d/awstats.conf


Restart Apache.
# /etc/init.d/apache2 restart




Enable ipduh_intel awstats plugin and disable PTR lookups.
# wget https://raw.githubusercontent.com/ipduh/apache2_awstats_conf/master/awstats.conf.local -O /etc/awstats/awstats.conf.local
IP numbers relay much more information than PTR names and PTR names can be (and commonly are) abused-manipulated.



Install the ipduh_intel awstats plugin.
# wget https://raw.githubusercontent.com/ipduh/awstats_plugins/master/ipduh_intel.pm -O /usr/share/awstats/plugins/ipduh_intel.pm




Create the apache password file and add the user 'user' with password 'userpass'
# htpasswd -cb /etc/awstats/A2Passwords user userpass
Add the user 'user2' with password 'user2pass' to the apache passwords file
# htpasswd -b /etc/awstats/A2Passwords user2 user2pass




Create an awstats configuration file for each (virtual) host in /etc/awstats. The configuration files should have the form awstats.host.conf e.g. for a host named example.com the configuration file would be awstats.example.com.conf and it could look like the following.
Include "/etc/awstats/awstats.conf"
SiteDomain="example.com"
HostAliases="www.example.com"
DirData="/logs/sites/example.com/awstats"
LogFile="/logs/sites/example.com/access_all"





Analyze for first time the access logs of one host.
# cat /logs/sites/example.com/access/* >> /logs/sites/example.com/access_all
# /usr/lib/cgi-bin/awstats.pl --configdir=/etc/awstats/ -config=example.com




View the awstats analysis with a web browser at http://example.com/awstats/awstats.pl?config=example.com



Get rid of debian package cronjob
# rm /etc/cron.d/awstats




Install debian packaged awstats



BGP as IGP with next-hop-self RR vs Fully Connected Mesh





A comparison of BGP as iGP with next-hop-self in a fully connected mesh vs BGP as iGP with next-hop-self with two Route Reflectors.

This is an effort to figure out the best of the two setups in terms of configuration and maintenance cost and it is inspired by a quest in the AWMN mailing list to find the best setup for AWMN nodes with many routers .

( AWMN is a wireless BGP internet where each wireless node has an Autonomous System Number and 1 to 15 routers with wireless interfaces. The routing within each node is done with static Routes or some iGP --usually OSPF-- or iBGP with next-hop-self. )



I assume that:

The maintenance cost is equal to the number of iBGP sessions --the number of connections in the mesh.

The total configuration cost is equal to the number of (neighbor) configuration stanzas for all iBGP connections.

The cost of adding a router is equal to the number of (neighbor) iBGP configuration stanzas needed in all the nodes in the mesh.













Get a little program that prints tables of maintenance and configuration costs for both setups.
$ wget https://raw.githubusercontent.com/ipduh/fmvsrr/master/fmvsrr.pl && chmod 755 fmvsrr.pl


Print costs for 2 to 27 routers.
$ ./fmvsrr.pl 27
N    = Number of routers
Πfm  = Maintenance Cost in a Fully Connected Mesh
Πrr  = Maintenance Cost in a Two Route Reflectors Setup
Kfm  = Total Configuration Cost in a Fully Connected Mesh
Krr  = Total Configuration Cost in a Two Route Reflectors Setup
Nfm  = Cost of adding one router in a Fully Connected Mesh
Nrr  = Cost of adding one router in a Two Route Reflectors Setup

N=2 Πfm=2  Πrr=2+  Kfm=2  Krr=2+  Nfm=2  Nrr=2+
N=3 Πfm=3  Πrr=3+  Kfm=6  Krr=3+  Nfm=6  Nrr=3
Ν=4  Πfm=6  Πrr=6  Kfm=12  Krr=9  Nfm=6  Nrr=3
Ν=5  Πfm=10  Πrr=7  Kfm=20  Krr=11  Nfm=8  Nrr=3
Ν=6  Πfm=15  Πrr=8  Kfm=30  Krr=13  Nfm=10  Nrr=3
Ν=7  Πfm=21  Πrr=9  Kfm=42  Krr=15  Nfm=12  Nrr=3
Ν=8  Πfm=28  Πrr=10  Kfm=56  Krr=17  Nfm=14  Nrr=3
Ν=9  Πfm=36  Πrr=11  Kfm=72  Krr=19  Nfm=16  Nrr=3
Ν=10  Πfm=45  Πrr=12  Kfm=90  Krr=21  Nfm=18  Nrr=3
Ν=11  Πfm=55  Πrr=13  Kfm=110  Krr=23  Nfm=20  Nrr=3
Ν=12  Πfm=66  Πrr=14  Kfm=132  Krr=25  Nfm=22  Nrr=3
Ν=13  Πfm=78  Πrr=15  Kfm=156  Krr=27  Nfm=24  Nrr=3
Ν=14  Πfm=91  Πrr=16  Kfm=182  Krr=29  Nfm=26  Nrr=3
Ν=15  Πfm=105  Πrr=17  Kfm=210  Krr=31  Nfm=28  Nrr=3
Ν=16  Πfm=120  Πrr=18  Kfm=240  Krr=33  Nfm=30  Nrr=3
Ν=17  Πfm=136  Πrr=19  Kfm=272  Krr=35  Nfm=32  Nrr=3
Ν=18  Πfm=153  Πrr=20  Kfm=306  Krr=37  Nfm=34  Nrr=3
Ν=19  Πfm=171  Πrr=21  Kfm=342  Krr=39  Nfm=36  Nrr=3
Ν=20  Πfm=190  Πrr=22  Kfm=380  Krr=41  Nfm=38  Nrr=3
Ν=21  Πfm=210  Πrr=23  Kfm=420  Krr=43  Nfm=40  Nrr=3
Ν=22  Πfm=231  Πrr=24  Kfm=462  Krr=45  Nfm=42  Nrr=3
Ν=23  Πfm=253  Πrr=25  Kfm=506  Krr=47  Nfm=44  Nrr=3
Ν=24  Πfm=276  Πrr=26  Kfm=552  Krr=49  Nfm=46  Nrr=3
Ν=25  Πfm=300  Πrr=27  Kfm=600  Krr=51  Nfm=48  Nrr=3
Ν=26  Πfm=325  Πrr=28  Kfm=650  Krr=53  Nfm=50  Nrr=3
Ν=27  Πfm=351  Πrr=29  Kfm=702  Krr=55  Nfm=52  Nrr=3



When the full mesh topology is used in a node with 10 routers the configuration and maintenance cost is ~4.5 times larger from a two-route-reflectors setup and the 11th router would cost me ~20 configuration stanzas and logging in 11 routers instead of ~3 stanzas in three routers ...









Full Mesh vs Route Reflectors











TSIG authenticated zone transfers in Bind

Notes on setting up secret key authenticated TSIG zone transfers in Bind 9.8.

Create an 128b HMAC-SHA256 of type HOST key to use as the shared secret.
# dnssec-keygen -a hmac-sha256 -b 128 -n HOST gemlocgem
Kgemlocgem.+163+12752


The previous command creates two files.
# ls Kgemlo*
Kgemlocgem.+163+12752.key  Kgemlocgem.+163+12752.private


The 128b base-64 string we need for the shared secret is in both files.
# cat Kgemlocgem.+163+12752.key
gemlocgem. IN KEY 512 3 163 Wh47ever64iPdUhb9nd8hg==


Create a named.conf.keys file.
# cat named.conf.keys

key gemlocgem. {
  algorithm hmac-sha256;
  secret  "Wh47ever64iPdUhb9nd8hg==";
};



Make secret and named.conf.keys files non-readable by all in this system.
# chmod 640 Kgemlocgem.+163+12752.*
# chmod 640 named.conf.keys


Send named.conf.keys to the slave.
# toprod named.conf.keys


Include named.conf.keys and add server-key stanza in the named.conf of the server at 192.0.2.111
# cat named.conf

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.external";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.keys";

server 192.0.2.222 {
  transfer-format many-answers;
  keys { gemlocgem.; };
};



One of the name servers ( e.g. the slave) is at 192.0.2.222 and the other name server at 192.0.2.111

The named.conf file in the other server.
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.external";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.keys";

server 192.0.2.111 {
  transfer-format many-answers;
  keys { gemlocgem.; };
};


Adjust allow-updates and allow-transfer directives to use TSIG in the options of both servers e.g.
  allow-transfer { key gemlocgem. ; };
  allow-update { key gemlocgem. ; };
You may use and other allow-transfer directives that specify IP addresses.

The systems used.
# named -v
BIND 9.8.4-rpz2+rl005.12-P1
# cat /etc/issue /etc/debian_version 
Debian GNU/Linux 7 \n \l

7.7


TSIG authenticated zone transfers between Bind Servers



Change hostname in debian

A better way to change the hostname in debian systems.

# hostname -f
geminus


Sanity-check the list of /etc/* files in which the hostname appears.
# cd /etc
# grep -ril `hostname -f` /etc |tee hostname.files.list
/etc/mailname
/etc/hostname
/etc/exim4/update-exim4.conf.conf
/etc/hosts
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
The above list seems fine but imagine what it would happen if the hostname was eth or work.

Save each file that contains the hostname to file.0 and replace geminus (old hostname) with gem (new hostname).
# perl -i.0 -p -e 's/geminus/gem/g;' `cat ./hostname.files.list`


Restart services (ssh and exim in this case) or better reboot the system if you can afford it.
# reboot




Change the hostname in debian systems

LXC container start at boot

Start a Linux Container at boot time

See the containers ' status.
# lxc-list
RUNNING

FROZEN

STOPPED
  squeezie



Link the container's config file to /etc/lxc/auto so it starts at boot time.
# ln -s /var/lib/lxc/squeezie/config /etc/lxc/auto/squeezie
squeezie is the name of the container.

Test if you can afford to reboot the host.
# reboot


...

# lxc-list 
RUNNING
  squeezie (auto)

FROZEN

STOPPED





start a LinuX Container at boot



change container root password from the host

Change a container's root password (you forgot) from the host.

I think that the easiest way is to run passwd chrooted to the container's root.

e.g. for the squeezie host created by the squeeze template
# chroot /var/lib/lxc/squeezie/rootfs/ passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully




Change a container's root password from the host



debian - gnome - disable log out lock screen etc





Disable automatic log-out / screen lock on debian gnome desktops ...

bad idea for your workstation, even worst for your laptop but a friend desperately wants it and he could not figure it out.



Check which values-keys are set to true in the relative section of the 'registry'
$ dconf list /org/gnome/desktop/lockdown


Set disable-lock-screen and disable-log-out to true
$ dconf-editor
and check /org/gnome/desktop/lockdown/disable-lock-screen and /org/gnome/desktop/lockdown/disable-log-out



( dconf write /org/gnome/desktop/lockdown/x false|0|... does not work the way I expected it to work )




> System Settings > Brightness And Lock > Lock > OFF









debian gnome disable lock screen and user logout

virtualbox debian guest with tiny screen

To 'fix' display issues of a virtualbox debian(6) guest with tiny not-usable screen
...
ssh into the guest and
# apt-get install virtualbox-ose-dkms
# reboot








Fix display issues of virtual box debian guest

squeeze container on a wheezy host

Notes on putting a Debian squeeze Linux Container on a Debian Wheezy host.

The requirement; the Squeeze system in the container runs a TCP/IP application that should be accessible only by the host.



Create a bridge between a dummy network interface and the network interface used by the container.

Load dummy module (with numdummies=1) at startup.
# echo dummy >> /etc/modules


Install the Linux ethernet bridge utilities.
# apt-get install bridge-utils


Add stanzas that create an inhost bridge that contains a dummy to /etc/network/interfaces
auto dummy0
  iface dummy0 inet static

auto etherisland
  iface etherisland inet static
  address 172.16.17.18
  netmask 255.255.255.128
  bridge_ports dummy0
  bridge_stp  off
  bridge_waitport 0
  bridge_fd 0



Load one dummy interface and restart networking.
# modprobe dummy
# /etc/init.d/networking restart




Install lxc and prerequisites.
# apt-get install lxc
which also installs debootstrap libcap2-bin and libpam-cap.

Mount control groups hierarchy now and at boot.
# mount /sys/fs/cgroup/
# echo "cgroup /sys/fs/cgroup  cgroup  defaults  0  0" >> /etc/fstab


Check your kernel for lxc support.
# lxc-checkconfig


Get the squeeze template.
# wget https://raw.githubusercontent.com/ipduh/lxc-squeeze/master/lxc-squeeze -O /usr/share/lxc/templates/lxc-squeeze


Allow execution to all.
# chmod 755 /usr/share/lxc/templates/lxc-squeeze


Create the Squeeze Container.
# lxc-create -n squeezie -t squeeze


Start the container in the background.
# lxc-start -n squeezie -d


Console into the squeezie container.
# lxc-console -n squeezie

Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Debian GNU/Linux 6.0 squeezie tty1

squeezie login: root
Password: 
Linux squeezie 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

root@squeezie:~#
The password set by the template is squeezie.
Alternatively, you may ssh to squeezie from the host.

Change the root password
root@squeezie:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully



Give Temporary Internet Connectivity to the Squeeze Container.
root@squeezie:~# route add default gw 172.16.17.18
and in the host
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE -s 172.16.17.0/25
To disable the Internet Connectivity reset your Firewall e.g.
# /etc/bif


Forward the application's TCP ports e.g. for port 80 and port 443.
# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.16.17.16:80
# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 172.16.17.16:443




Squeeze LXC on Wheezy