Thursday, March 22, 2012

OpenSUSE - VNC - Remmina



You can find this app in Ubuntu repo., however, it's not the case of OpenSUSE.
After googling for some minutes, I found solutions as follow:


linux:/home # zypper ar -f http://download.opensuse.org/repositories/X11:/xfce:/nilda/openSUSE_11.3/X11:xfce:nilda.repo
linux:/home# zypper install remmina

Tuesday, March 13, 2012

THUNDERBIRD GOOGLE CALENDAR



HOW TO SYNCHRONIZE GOOGLE CALENDAR WITH THUNDERBIRD


You can use Lightning to get a calendar that's fully integrated with Thunderbird, but what about Google Calendar synchronization? Well, there's an extension called "Provider for Google Calendar", which lets Lightning read and write events to Google Calendar. 

For older Ubuntu versions (11.04, 10.10 and 10.04), you can install Thunderbird 10 (soon, version 11 will be available) using the stable Thunderbird PPA: 

sudo add-apt-repository ppa:mozillateam/thunderbird-stable
sudo apt-get update
sudo apt-get install thunderbird

sudo apt-get install xul-ext-lightning xul-ext-gdata-provider

... 



Tuesday, March 6, 2012

BIND allow-recursion



Configure Bind



You should always set up at least two name servers, and designate one as the master.
Do not use these files without modification. These files must be modified to match your hostnames.
  1. Create /etc/named.conf for the master server. Note that the path for the db files ( var/named/ ) is specified in the named.conf file. The format for version 9 is different from that shown in the book. In this example, the access control list (acl) is disabled.
  2. Change the pid-file location to /var/named/named.pid. This is necessary because named is not being run as root and can't access /var/run.
  3. Create named.conf for the slave server(s).
  4. Create user 'named' and group 'named'. In /etc/passwd:
     named:x:44:44:Nameserver Daemon:/var/named:/bin/nologin 
    In /etc/group :
     named:x:44:named
  5. Create a /var/named/ directory, owned by named.named and put the db files there. They should also be owned by named.named. Make sure /var/named/ has the following permissions:
          drwxr-xr-x   2 named    root         4096 Apr  1 14:42 named
  6. Set the options in named.conf as needed for security.
    options {
            directory "/var/named";
            pid-file "/var/named/named.pid";
            allow-query { "any"; };
            allow-transfer { 63.127.146.192/26;  65.198.102.64/26;};
            allow-recursion { 63.127.146.192/26;  65.198.102.64/26;};
    };

    The "allow-recursion" option prevents third parties from leeching your bandwidth by using your server instead of their own server to do their DNS. With this line, only the specified networks are allowed to perform recursive queries, i.e. queries about names for which the server is not authoritative. Answering recursive queries also makes your server vulnerable to cache poisoning. 


http://fixunix.com/dns/51724-re-bind-9-allow-recursion-limited-localhost.html


dan_delspam wrote:
> Hello.
>
> I am trying to setup a DNS that is a master for the world and a caching
> name server for the localhost only.
> I have been able to setup something quite near of this, but here is my
> problem:
>
> When I do a query of an external domain name from the outside, the
> query is properly blocked. However, if I do query the server from my
> server (localhost) for the same domain name, and then try the first
> operation of querying the server from the outside, then the query is
> successful that time.
>
> To be clearer:
>
> 1. external query blocks ok:
> from ip 192.168.0.100: nslookup google.com 192.168.0.1
> *** Can't find google.com: No answer
>
> 2. internal query works fine as wanted:
> from ip 192.168.0.1: nslookup google.com 192.168.0.1
> Name: google.com
> Address: 64.233.167.99
>
> 3. external query like point 1 again is accepted this time:
> from ip 192.168.0.100: nslookup google.com 192.168.0.1
> Name: google.com
> Address: 64.233.167.99
>
> It's like if the 'allow-recursion' directive would not allow to make a
> recursion (relaying the request to the source DNS server), but would
> still allow external requests to access the internal cache of the DNS.
> I don't know if this is the normal behaviour, bu my question is to know
> if there is a way to block all requests of domain which are not my
> master domain names for the outside.
> I thought that this directive would take care of it, but it doesn't
> seem so.
> Can someone also try that and tell me if this is happening elsewhere or
> if this is a misconfiguration of my DNS ?
>
> I am using Bind 9.2.4-2 on a CentOS 4.3 server.
>
> Here is my configuration file (top only, the rest are only zones):
>
> options {
> directory "/var/named";
> recursion yes; // prevent caching for all by default,
> overridden below.
> allow-recursion {127.0.0.1;};
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> query-source port 53; // because firewall allows port 53 only
> allow-transfer {"none"; }; // transfer will be allowed per
> zone below.
> };
>
> controls {
> inet 127.0.0.1 allow { "none"; };
> };
>
> Thanks for any help.
> Daniel





Answering from cache doesn't require recursion, so allow-recursion has
no effect on it.

Solutions:
1) Use separate views for inside versus outside, with recursion turned
off for the "outside" view (this will result in a "root referral" being
returned if something outside of your hosted zones is queried),
2) Only allow queries from your internal clients by default, and then
override that default with an "allow-query { any; };" on each and every
zone you host to the Internet (this will result in a REFUSED response
being returned for queries outside of your hosted zones), or
3) Wait until BIND 9.4.0 comes out, since it addresses this need with
"allow-query-cache", see http://www.isc.org/sw/bind/bind9.4-beta.php
(REFUSED also).




http://support.menandmice.com/jforum/posts/list/25.page


ISC Support Bulletin - July 2007 
Document last updated: 2007-07-30 

There has been some confusion surrounding the changes to the "allow-recursion" and "allow-query-cache" options made with BIND 9.4.1-P1. 

This document will attempt to clarify the change and the impact that it makes on BIND servers. 

In BIND 9.3, there was no segregation of queries between cache and authoritative data. 

The release of BIND 9.4 added fine-grained differentiation between queries against authoritative data ("allow-query") and cached data ("allow-query-cache"). This allows more precise control, particularly if you do not want your clients to use any cached data, for example, in an authoritative-only nameserver. 

Prior to the release of BIND 9.4.1-P1, the default action of "allow-recursion" and "allow-query-cache" was to permit the query. The P1 patch to BIND 9.4.1 caused two changes in this behavior: 

1) If not explicitly set, the ACLs for "allow-query-cache" and "allow-recursion" were set to "localnets; localhost;". 

2) If either "allow-query-cache" or "allow-recursion" was set, the other would be set the same value. 

Upgrading from the BIND 9.3 branch to BIND 9.4.1-P1 will significantly restrict those servers that were previously recursive servers for more than "localhost; localnets;" unless configuration changes are made. 

To retain the behavior prior to BIND 9.4.1-P1, the following entries should be created in your named.conf file: 
Code:

 options {
     ...
     allow-recursion { any; };
     allow-query { any; };
     allow-query-cache { any; };
     ...
 };
 

We strongly advise against this configuration because clients spoofing queries can use your servers to launch distributed denial-of-service attacks. 

The recommended method is to create ACLs that match hosts that should be allowed access to cache and recursion on the servers. For example, if you wanted to provided recursion and access to the cache to clients you trusted, you could list them in an ACL such as the following: 
Code:
 acl "trusted" {
     192.168.0.0/16;
     10.153.154.0/24;
     localhost;
     localnets;
 };
 
 options {
     ...
     allow-query { any; };
     allow-recursion { trusted; };
     allow-query-cache { trusted; };
     ...
 };
 

This example ACL includes 192.168.0.0/16 and 10.153.154.0/24 as sample networks that would require access. You must replace these sample networks with networks that correctly reflect your environment. This will allow anyone to query your server for authoritative data, but only those hosts within the "trusted" ACL access to your cache and recursion.