wasil.org Abandon the search for Truth; settle for a good fantasy

23Jun/120

Installing node.js on Fedora

Hi,
Today I tried to install node.js on my Fedora and I got stuck after issu­ing ./configure command:

[..]error: could not configure a cxx compiler!

I have to admit that I was rather sur­prised because I have already installed gcc and cpp pack­ages. What was actu­ally miss­ing was this: gcc-c++.
You can get it with:

yum install gcc-c++

Run­ning ./configure again and… next stop:

error: Could not autodetect OpenSSL support. Make sure OpenSSL development packages are installed. Use configure --without-ssl to disable this message.

This time it was fixed by installing openssl-devel pack­age with

yum install openssl-devel

That’s it, now you should have work­ing node.js

Go nuts! ;)

19Aug/111

(archive) GitLab installation on Fedora 16 (with gitolite)

This is old ver­sion of my tuto­r­ial. Most recent ver­sion can be found here

Git­Lab is a won­der­ful piece of soft­ware made by these guys and I’d like to try and install it on Fedora 16 sys­tem, as it is most recent Fedora OS at the time I am writ­nig this. I will base my tuto­r­ial on on found here by Déja. Also on my way to suc­cess­ful install I’ve stum­bled upon this descrip­tion, so I might have gain some expe­ri­ence from it too.

Git­Lab is Ruby on Rails appli­ca­tion and it takes some expe­ri­ence to get it all work­ing because of many, many, many depen­den­cies and pack­ages it needs. It’s noth­ing like sim­ple PHP on Apache instal­la­tion. But it works and it’s worth it, I assure you :)

Let’s begin! (by the way: I per­form all as root user — again: test environment)

small edit: For peo­ple who only want this to work and not nec­es­sar­ily wish to know how and why, I have pre­pared easy instal­la­tion scripts in here
  1. First of all: I am work­ing on vir­tual machine with brand new and fresh Fedora 16 installed. Min­i­mal instal­la­tion, just to make sure noth­ing messes with Git­Lab. Con­sider this a test environment.
  2. Once you have your OS ready, update it with yum update and also install some pack­ages you will need on the way:
    yum install make openssh-clients gcc libxml2 libxml2-devel \ 
    libxslt libxslt-devel python-devel
  3. Check what ver­sion of ruby is avail­able via yum. Git­Lab needs at least ver­sion 1.9.2
    yum info ruby

    on mine it says that the only avail­able ver­sion for me is 1.8.7.35 so I have to get it some­where else.

  4. Method #1.
    I will do as it says here. I have tried it before and it works flaw­lessly. With one or two catches of course ;)Men­tioned catches and tips:

    • you need wget, if you don’t have it already use
      yum install -y wget
    • other needed pack­ages (plus few depen­den­cies) can be obtained by typing:
      yum install -y readline-devel ncurses-devel gdbm-devel \ 
      glibc-devel tcl-devel openssl-devel db4-devel byacc
    • if you are using vir­tual machine, like me, you can first make a snap­shot of it, then build ruby RPM pack­age, copy it to you host machine (or net­work share or what­ever place out­side vir­tual machine) and then go back in time to you snap­shot. Voila! Clean sys­tem ready for fur­ther installing Git­Lab. All you need to do is install ear­lier cre­ated ruby RPM. Any­way this is what I’m gonna do today. Keep it clean.
    • last step — your RPM will end up some­where in ~/rpmbuilds/RPMS direc­tory. It will reside in folder named after your sys­tem archi­tec­ture, in my case: i386

    And here is how:

    yum install -y rpm-build rpmdevtools
    rpmdev-setuptree
    cd ~/rpmbuild/SOURCES
    wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p290.tar.gz
    cd ~/rpmbuild/SPECS
    curl https://raw.github.com/imeyer/ruby-1.9.2-rpm/master/ruby19.spec > ruby19.spec
    rpmbuild -bb ruby19.spec
    rpm -Uvh ~/rpmbuild/RPMS/x86_64/ruby-1.9.2p290-2.ruby-1.9.2p290-2.i386.rpm
    

    I took my VM about 4 min­utes to com­pile and pre­pare RPM. Not so bad.
    Now I go back in time in my VM and install newly cre­ated RPM with

    rpm -Uvh ruby-1.9.2p290-2.fc16.i386.rpm
  5. Method #2. ( I pre­fer this one so far)
    EDIT: I have switched to ruby 1.9.3p0 — it works and starts a lot faster, you can use it instead of 1.9.2-p290 in this guide.

    I will use RVM, which stands for Ruby Ver­sion Man­ager — bril­liant tool, which you can use to install and man­age your Ruby with ease. Let’s check it out, shall we?

    sudo bash -s stable < <(curl -sk https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
    
    source /etc/profile.d/rvm.sh
    
    rvm install ruby-1.9.2-p290
    
    rvm use ruby-1.9.2-p290 --default
    

    Done. Just like that we have oper­a­tional Ruby 1.9.2-p290. No RPMs, bo going back in time.. nice, huh? :)

  6. Good. Small (nice) sur­prise: our RPM installed ruby gems for us, so now we only have to get rails gem.
    first, just to make sure every­thing is up to date, execute:
    gem update --system

    now install rails with:

    gem install rails
  7. Now we will install apache2 as a web­server and Pas­sen­ger for ruby apps deploy­ment. I know that most Git­Lab tuto­ri­als use nginx but I really like apache ;)
    yum install -y httpd
    gem install passenger

    as I men­tioned: I use apache, so I will need pas­sen­ger mod­ule for it:
    first some required packages:

    yum install gcc-c++ curl-devel openssl-devel zlib-devel \ 
    httpd-devel apr-devel apr-util-devel

    an then use

    passenger-install-apache2-module

    in order to install it.it gives you 2 infor­ma­tion on how to pro­ceed with apache configuration:

    • add fol­low­ing lines to /etc/httpd/conf/httpd.conf (at the very end):
      LoadModule passenger_module /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.11/ext/apache2/mod_passenger.so
      PassengerRoot /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.11
      PassengerRuby /usr/bin/ruby
      
    • and then cre­ate file named default.conf (or gitlab.conf, or some­thing other you fancy) in /etc/httpd/conf.d/ con­tain­ing these lines (remem­ber to change to fit your environment):
      <VirtualHost *:80>
      ServerName www.yourhost.com
      DocumentRoot /somewhere/public
      <Directory /somewhere/public>
      AllowOverride all
      Options -MultiViews
      </Directory>
      </VirtualHost>
      

      (don’t worry, we’ll come back to this one later)

  8. Now it is time for gito­lite. I won’t use gito­sis because it is not actively devel­oped any more and I found that new Git­Lab works bet­ter with gitolite.install it with
    yum install -y gitolite

    now, wasn’t that quick? :)

  9. Now we will need to cre­ate new gito­lite server con­fig­u­ra­tion and in order to do that we have to gen­er­ate SSH key-pair. But first things first.
    To get us started su into gito­lite user with

    su - gitolite

    now try to log into local­host via SSH -> it’s small thing which will make our life eas­ier in the future.

    ssh localhost

    Just make it add local­host to list of known host — no need to actu­ally authen­ti­cate. SSH cre­ated for us ~/.ssh direc­tory. That’s nice.SSH key gen­er­a­tion is as easy as:

    ssh-keygen -t rsa

    use default path for sav­ing key-pair (/var/lib/gitolite/.ssh/id_rsa) and no para­phrase. Test envi­ron­ment. Just a reminder.as for ini­tial­iza­tion of gito­lite repository:

    gl-setup .ssh/id_rsa.pub

    next hit ENTER and edit will open, change value of

    $REPO_UMASK to 0007

    as men­tioned hereLook like we are done here. Exit gito­lite user shell and return to being almighty root himself ;)

  10. OK, time for next require­ments: python Pip, I will go with method from orig­i­nal post and NOT use yum for that.
    curl http://python-distribute.org/distribute_setup.py | python
    

    and then

    easy_install pip
    
  11. Data­base. We need it. We have it already — it was installed on the way as a depen­dency. Just to make sure check if you have SQLite at list ver­sion 3.6 with:
    yum info sqlite

    I have 3.7.7.1. All we need is SQLite devel­op­ment pack­age, get it with:

    yum install sqlite-devel
  12. And now the main event! GitLabHQ!

    I like install web apps in /var/www so we will go there and git clone GitLab:

    cd /var/www
    
    git clone git://github.com/gitlabhq/gitlabhq.git
    
    cd gitlabhq/
    

    we need to use pip to install some python dependencies:

    pip install pygments

    and bundler gem so it can later on do most of the work for us:

    gem install bundler

    finally (remem­ber to be in Git­Lab direc­tory):

    bundle install

    (go get your­self a cof­fee or other treat — it takes w while)

  13. DB setup:
    EDIT: For Git­Lab ver­sion 2.1 install Redis — with­out it rake will fail.:
    yum install redis libicu-devel
    service redis start
    

    And now data­base setup and import:

    RAILS_ENV=production rake db:setup
    RAILS_ENV=production rake db:seed_fu
    

    TIP: if you get errors here, check if you don’t have 2 ver­sions of rake installed (I had some­how): 0.8.7 and 0.9.2. If you do, remove older with:

    gem uninstall rake

    and choose appro­pri­ate ver­sion. If you still have prob­lems try:

    gem install rake

    -> don’t know why, but if it installs again same ver­sion of rake, it works.

  14. Apache vir­tual host con­fig­u­ra­tion should look some­thing like this (I told you, we will get back to that):file: /etc/httpd/conf.d/gitlab.conf
    <VirtualHost *:80>
    ServerName www.yourhost.com
    DocumentRoot /var/www/gitlabhq/public
    <Directory /var/www/gitlabhq/public>
    AllowOverride all
    Options -MultiViews
    </Directory>
    </VirtualHost>
    
  15. set cor­rect set­tings in /var/www/gitlabhq/config/gitlab.yml

    in my case:# Git Host­ing configuration

    git_host:
    system: gitolite
    admin_uri: gitolite@localhost:gitolite-admin
    base_path: /var/lib/gitolite/repositories/
    host: localhost
    git_user: gitolite
    # port: 22
    
  16. enable apache user, co you can su into this account:
    usermod -s /bin/bash -d /var/www/ apache

    also give him per­mis­sions to his own home direc­tory with:

    chown -R apache:apache /var/www/

    (I know this kinda over­rides last chown command…)

  17. do:
    su - apache && ssh localhost

    (same thing as in step 8. with know_hosts file. )
    exit apache’s shell and as root copy id_rsa pri­vate key from /var/lib/gitolite/.ssh/ to /var/www/.ssh/ and make apache it’s owner with:

    cp -f /var/lib/gitolite/.ssh/id_rsa /var/www/.ssh/ \
    && chown apache:apache /var/www/.ssh/id_rsa \
    && chmod 600 /var/www/.ssh/id_rsa
  18. add apache user to gito­lite group with:
    usermod -a -G gitolite apache
  19. check if repos­i­to­ries direc­tory has cor­rect per­mis­sions, it should be 770. You can set it with
    chmod 770 /var/lib/gitolite/repositories/
  20. dou­ble check your fire­wall (for exam­ple ipt­a­bles) if it allows con­nec­tions on port 80 to your server.
  21. start apache server with:
    service httpd start
  22. Now it all should work. Fin­gers crossed.. go to http://www.yourhost.com
  23. Now you should be able to log in using these cre­den­tials:

    user: admin@local.host
    pass: 5iveL!fe

    and you’re in :)

It wasn’t so hard, wasn’t it? ;)

Trou­bleshoot­ing:

  1. I get error 500 when I enter par­tic­u­lar project and try to get into it’s “Admin” sec­tion. Don’t know how to fix it yet.To fix it, check if repos­i­to­ries direc­tory has cor­rect per­mis­sions, it should be 770. You can set it with
    chmod 770 /var/lib/gitolite/repositories/
  2. If Pas­sen­ger insists, that we don’t have or he can’t see grit library (gem actu­ally, as far as I know) even though we have it.

    https://github.com/gitlabhq/grit.git (at mas­ter) is not checked out. Please run ‘bun­dle install‘ (Bundler::GitError)

    I didn’t have gem grit installed, do:

    gem install grit
    

    also it won’t hurt to update all gems with:

    gem update

    Only res­o­lu­tion to this prob­lem I have found is to run bun­dle again as a user who runs apache server: apache.Su into apache account with

    su - apache

    and try:

    gem install grit

    you’ll get error:

    You don't have write permissions into the /usr/lib/ruby/gems/1.9.1 directory.

    As root change it’s own­er­ship to apache user with:

    chown apache:root -R /usr/lib/ruby/gems

    I know that is not great res­o­lu­tion but it worked for me. If you’ll hap­pen to know bet­ter way — please let me know, so I can update this tuto­r­ial and my knowl­edge of course ;)

    Edit

    I found another solu­tion (instead of chang­ing per­mis­sions): after first

    bundle install

    edit Gem­file and in lines con­tain­ing “git:” remove every­thing after first comma, for example:

    gem "grit", :git => "https://github.com/gitlabhq/grit.git"

    should be

    gem "grit"

    then do again

    bundle install

    and now pas­sen­ger shouldn’t com­plain any more.

Tagged as: , 1 Comment
14May/110

dnsmasq - DNS and DHCP server

Dns­masq is a sim­ple server pro­vid­ing the DNS and DHCP ser­vices for a local area net­work (LAN) and as its cre­ator say — it will be work­ing very well on home net­works and small busi­ness envi­ron­ments, up to roughly 1000 work­sta­tions. More infor­ma­tion about it in the author’s web­site: http://www.thekelleys.org.uk/dnsmasq/doc.html

  1. But why?
    Good ques­tion. As a rule, if you already have a local net­work at home, then your are prob­a­bly used to mov­ing around it either by using computer’s IP addresses using the local envi­ron­ment of Win­dows and the names of work­sta­tions in the work group. The lat­ter is quite com­fort­able, but will work only in net­works with Win­dows oper­at­ing sys­tems, maybe also with dif­fer­ent Unix’s or Linux’s, but this in turn requires the con­fig­u­ra­tion of the Samba server, which is beyond the scope of this text.
    Now let’s think how beau­ti­ful it would have been if, instead of IP addresses, each com­puter was rec­og­nized by its unique name, just like web pages. This would also include net­work print­ers, routers and other devices. This is what dns­masq can do for us. It will allow us to find any of net­work devices receiv­ing IP addresses auto­mat­i­cally via DHCP or sta­t­i­cally added to server configuration.Instead of seek­ing to enter the net­work share:

    \\192.168.0.4\share

    Type:
    \\our.server.domain\share

    Eas­ier to remem­ber, right? Now, if the address of a machine iden­ti­fied as “our.server” changes, we do not even need to know present IP address, because dns­masq will guide us to him flawlessly.

    Now that we know what we might use it for… let’s get started! :)

  2. Instal­la­tion
    Instal­la­tion depends on the envi­ron­ment in which we work, I will focus on Linux, and specif­i­cally on the two most pop­u­lar dis­tri­b­u­tions: Fedora (as well as Red Hat, Cen­tos) and Debian (Ubuntu and other Debian like). For instal­la­tion you will need root priv­i­leges. You can either log on as root, or add before each fol­low­ing com­mand: sudo
    For exam­ple: sudo yum update

    • Fedora
      use com­mand:
      yum update (in case there are updated pack­ages for our sys­tem)
      yum install dns­masq  

    • Debian
      use com­mand:
      apti­tude update && apti­tude safe-upgrade
      (in case there are updated pack­ages for our sys­tem)
      apti­tude install dns­masq

  3. The con­fig­u­ra­tion file is called dnsmasq.conf and is located in /etc direc­tory.
    In addi­tion, dns­masq uses /etc /hosts as a source of infor­ma­tion about the hosts with sta­t­i­cally assigned IP addresses, that is those not assigned by the DHCP and /etc /resolv.conf — thus receives infor­ma­tion about DNS servers, which it will use.
    It is very well doc­u­mented in the con­fig­u­ra­tion file com­ments, so I’ll skip the detailed instruc­tions, but I will focus on sev­eral options that are needed to start with.

    • domain-needed — means that dns­masq will for­ward only dns queries that have a domain name in the address
    • bogus-priv — means that dns­masq will for­ward only dns queries that are in routable IP ranges
    • inter­face = {eth0, eth1, …} — if you have more than one net­work inter­face, you can make dns­masq lis­ten only on one of them
    • except-interface = {eth0, eth1, …} as well as ear­lier but dns­masq should lis­ten on all inter­faces except the specified
    • expand-hosts — tells dns­masq to add your domain to the host’s name and works in con­junc­tion with vari­able domain
    • domain — your domain name
    • dhcp-range = 192.168.0.30,192.168.0.40,24 h — used to acti­vate the DHCP server and set­ting the scope of the assigned addresses to 192.168.0.30–40 and time of lease (rent) for 24 hours. If we have two sub­nets (VLANs or two net­work cards), we can define the vari­ables twice, pro­vided that dns­masq is con­fig­ured to lis­ten on both interfaces
    • dhcp-host = 00:11:22:33:44:55,192.168.0.36 — def­i­n­i­tion of the host, which on each con­nec­tion should have the same IP address. Host authen­ti­ca­tion is done using the hard­ware address of net­work adapter MAC. In our case, the host with MAC address 00:11:22:33:44:55 will always receive the address of 192.168.0.36
  4. Set­ting these val­ues ​​will allow us to start using dns­masq on our net­work and enjoy host names instead of IP addresses.
  5. Addi­tional Information
    • entries in /etc/hosts look as fol­lows:
      IP_address host­name
      For exam­ple: 192.168.0.21 Server
    • entries in /etc/resolv.conf look like:
      name­server IP_address
      For exam­ple: name­server 194.204.152.34
    • in case of dns­do­main­name errors while restart­ing dns­masq ser­vice you should check the file /etc/hosts.
      The entry for 127.0.0.1 local­host should con­tain addi­tion­ally your_server.your_domain entry, for exam­ple:
      127.0.0.1 local­host server.domain.com
      After that you may need the restart of the sys­tem or net­work services.
    • in the case of Fedora, and other Red Hat like: in /etc/sysconfig/network should be an entry:
      HOSTNAME = your_serever.your_domain.com
    • if hosts with IP addresses sta­t­i­cally defined could also use dns­masq DNS server, you must replace their exist­ing DNS servers to the IP address of our server that is run­ning dnsmasq.
20Jun/100

Zadania Cron wszystkich użytkowników

Cza­sem pojawia się potrzeba wyświ­etle­nia zadań Cron wszys­t­kich użytkown­ików w systemie.

for user in $(cut -f1 -d: /etc/passwd); do crontab  -u $user  -l; done

A dla konkret­nego użytkown­ika można zas­tosować polecenie:

for user in $(cut -f1 -d: /etc/passwd | grep USER); do crontab  -u $user  -l; done

gdzie, USER = nazwa szukanego użytkown­ikaCza­sem pojawia się potrzeba wyświ­etle­nia zadań Cron wszys­t­kich użytkown­ików w systemie.

for user in $(cut -f1 -d: /etc/passwd); do crontab  -u $user  -l; done

A dla konkret­nego użytkown­ika można zas­tosować polecenie:

for user in $(cut -f1 -d: /etc/passwd | grep USER); do crontab  -u $user  -l; done

gdzie, USER = nazwa szukanego użytkownika

Tagged as: , No Comments
20Jun/100

Squid transparent proxy

Squid ( http://www.squid-cache.org ) jest opro­gramowaniem umożli­wia­ją­cym fil­trowanie ruchu sieciowego, ale nie był to początkowy zamysł jego twór­ców. Z założe­nia Squid miał umożli­wić tworze­nie pamięci podręcznej treści ( grafik itp. ) pobier­anych z Inter­netu przez użytkown­ików w cza­sie ser­fowa­nia po nim.

Jedną z możli­wości ofer­owanych przez Squid jest fil­trowanie stron jakie moga odwiedzać użytkown­icy zna­j­du­jący się w naszej sieci.

Więc po kolei :)

Zwycza­jowo, to znaczy domyśl­nie, Squid korzysta z portu 3128, ale na nasze potrzeby to nie jest wystar­cza­jące. Dlaczego? Oznacza to, że jak już wszys­tko skon­fig­u­ru­jemy, ustaw­imy i będzie dzi­ałało to i tak niewiele nam po tym, bo użytkown­icy naszej sieci będą musieli dobrowol­nie ustawić w swoich przeglą­dark­ach ustaw­ienia adresu naszego ser­w­era Squid oraz portu. Przyz­nam szcz­erze, że jakoś nie widzę u nich zach­wytu, kiedy zori­en­tują się, że owocuje to niczym więcej poza ograniczeni­ami nałożonymi przez nas. I tutaj nad­chodzi czas na wytłu­macze­nie drugiego słowa z tytułu niniejszego artykułu: trans­par­ent. Jest to mag­iczne słowo oznacza­jące “przezroczysty”. Co to oznacza dla nas? W najwięk­szym uproszcze­niu cały ruch sieciowy WWW zostanie domyśl­nie przekierowany tak, aby prze­chodził przez nasz ser­wer proxy Squid i to w dodatku bez potrzeby żad­nej kon­fig­u­racji po stronie użytkown­ików, a co więcej — nie będą mogli nic na to poradzić :)

Oczy­wiś­cie można ustawić proxy korzys­ta­jąc wyłącznie z domyśl­nego trybu Squid’a i wymusić na użytkown­ikach korzys­tanie z niego ( czyli przy­mus kon­fig­u­racji przeglą­darki ) na zasadzie: nie skon­fig­u­ru­jesz — nie masz dostępu do stron WWW. Uważam, że takie rozwiązanie jest nieel­e­ganckie i dużo bardziej kłopotliwe w prak­tyce. O wiele łatwiej sterować dostępem cen­tral­nie, na naszym ser­w­erze, w kon­fig­u­racji Squid’a.

Po tym przy­długim wstępie zabier­amy się do pracy :)

1. Usługę Squid proxy staw­iamy najlepiej na ser­w­erze pełnią­cym rolę bramy ( ang. Gate­way ) ale nie koniecznie. Na potrzeby tego artykułu przyjmę, że będzie ona zain­stalowana właśnie na ser­w­erze — bramie. Dodam, że

2. Insta­lacja odbywa się w sposób stan­dar­d­owy, z paczek bina­rnych właś­ci­wych dla naszej dys­try­bucji Linux’a lub ewen­tu­al­nie ( czego oso­biś­cie nie prak­tykuję ) dla Windows’a. Insta­lacja opisana jest dokład­nie tutaj i nie wchodzi w zakres tego artykułu, chyba, że zaist­nieje taka potrzeba, żeby go o te infor­ma­cje wzbogacić.

3. Kon­fig­u­racja usługi Squid odbywa się poprzez edy­cje pliku /etc/squid/squid.conf ( dla Debian’a, lub ana­log­icznie w przy­padku innych dys­try­bucji Linux’a ).

UWAGA: opcje są wczy­ty­wane po kolei od początku pliku kon­fig­u­ra­cyjnego do końca!

Jest to ważne, ponieważ można się łatwo pogu­bić i doszuki­wać przy­czyny nie dzi­ała­nia zdefin­iowanych przez nas fil­trów, ale to wyjdzie w praktyce.

Najpierw należy defin­iować zasady szczegółowe, a potem ogólne, ponieważ Squid bierze pod uwagę pier­wszą regułę jaką napotka i nie szuka dalej, więc jeśli najpierw umieścimy poz­wole­nie na dostęp dla wszys­t­kich, a potem zasady szczegółowe, to zostaną one zig­norowane, ponieważ Squid “zad­owoli” się regułką ogólną, którą napotkał wcześniej w pliku konfiguracyjnym.

4. Pier­wszą rzeczą jaką należy ustawić jest kto z naszej sieci będzie miał dostęp do usługi Squid, czyli inaczej mówiąc czyj ruch będzie fil­trowany i kto nie zostanie zablokowany całkowicie :)

acl moja_siec src X.X.X.0/24
http_access allow moja_siec

gdzie X.X.X.0/24 to nasza sieć, np. 10.0.1.0/24

Ten zapis poz­woli wszys­tkim kom­put­erom w naszej sieci na korzys­tanie ze Squid’a. To nie do końca jest nasz cel, ponieważ na tym etapie kon­fig­u­racji wszys­tko będzie śmi­gało bez żad­nych ograniczeń w tę i z powrotem bez żad­nej kontroli.

5. Teraz pora na kilka ograniczeń :)

Najlepiej ustaw­iać ograniczenia za pomocą odpowied­nich plików kon­fig­u­ra­cyjnych z lis­tami domen WWW, np:

domeny zabro­nione: /etc/squid/domeny_zabronione

domeny w tym pliku umieszczamy po jed­nej w każdej linijce.

w pliku kon­fig­u­ra­cyjnym Squid przed ( czyli wyżej, jak kto woli ) poprzed­nimi wpisami defini­u­ją­cymi dostęp dla całej sieci, doda­jemy linijki:

acl domeny_zabronione dstdomain -i "/etc/squid/domeny_zabronione"
http_access denydomeny_zabronione

to spowoduje, że żaden kom­puter w naszej sieci nie będzie mógł otworzyć stron zdefin­iowanych w tym pliku.

6. A teraz troszkę dokład­niejszej konfiguracji :)

Załóżmy, że mamy w sieci jakiś kom­puter, który ma mieć inne zasady dostępu do sieci niż pozostałe, np. nie móc wejść na konkretną stronę, powiedzmy www.strona1.com, wtedy jeszcze wcześniej niż poprzed­nia definicja należy dodać:

acl blokowany_komputer src X.X.X.21

acl lista_domen dstdomain -i "/etc/squid/lista_domen"

http_access deny blokowany_komputer lista_domen

a adres www.strona1.com umieś­cić w pliku /etc/squid/lista_domen

i już :)

przy­pom­i­nam jeszcze raz o kole­jności wpisów w pliku kon­fig­u­ra­cyjnym Squid’a.

7. Ostat­nie szlify ( prawie )

Aby sprawić by Squid zachowywał się jako trans­par­ent, czyli przezroczysty należy dopisać jeszcze te opcje:

http_port 127.0.0.1:3128 transparent
http_port X.X.X.X:3128  transparent

gdzie X.X.X.X jest adresem naszego ser­w­era, na którym zain­stalowany jest Squid

8. Teraz już naprawdę ostat­nie ustawienia :)

Pozostało ustaw­ie­nie reguły ipt­a­bles, tak aby kierowała cały ruch z portu 80 i 443, domyśl­nych dla stron WWW, na port 3128 Squid’a.

W moim przy­padku trzeba skon­fig­urować Shore­Wall, który zarządza regułami ipt­a­bles:
w /etc/shorewall/rules

ACCEPT	$FW	net	tcp	www
REDIRECT	loc	3128	tcp	www

w przy­padku zwykłego iptables:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 3128

9. No i restart usługi: /etc/init.d/squid restart ( lub ana­log­icznie dla innych dystrybucji )

29Dec/094

iptables i blokowanie stron WWW

Dzisiaj zajmiemy się kwestią cza­sem bardzo potrzebną, to znaczy blokowaniem użytkown­ikom sieci lokalnej dostępu do konkret­nych ser­wisów inter­ne­towych. Chodzi o sytu­ację, kiedy chcemy zablokować możli­wość “wchodzenia” tylko na niek­tóre strony a nie odwrot­nie, to znaczy zez­wolić tylko na niek­tóre, a zablokować domyśl­nie wszystkie.

Dodatkowym założe­niem naszego pro­jektu będzie to, że ruch zostanie przekierowany i użytkownik zami­ast trafić na stronę typu chomikuj.pl trafi na inną, zdefin­iowaną przez nas, np. google.pl lub naszą stronę firmową.

Można to osiągnąć za pomocą tabl­icy PREROUTING w iptables:

iptables -t nat -A PREROUTING -p tcp -s JAKAŚ_SIEĆ_LOKALNA \
-d ADRES_DOCELOWY --dport 80 -j DNAT --to ADRES_PRZEKIEROWANIA:80

i teraz tak:

JAKAŚ_SIEĆ_LOKALNA — nasza siec lokalna, np. 192.168.1.0/24
ADRES_DOCELOWY — adres IP strony, na która chce wejść użytkownik
ADRES_PRZEKIEROWANIA — adres IP, na jaki dostanie się użytkownik w wyniku dzi­ała­nia naszej regułki

Wszys­tko pięknie i w ogóle, ale jak to zro­bić jeśli adres, np rapidshare.com ma więcej niż jeden adres IP? tutaj z pomocą przy­chodzi BASH i skrypt w nim napisany, który wykonuje 2 rzeczy:

  1. zamienia adres domeny ( taki słowny ) na adres IP ( lub więcej adresów, jeśli takowe wys­tępują ). Czyni tę magię za pomocą polece­nia host –t a NAZWA_DOMENY oraz pętli FOR
  2. dla każdego odnalezionego adresu sto­suje regułkę, którą opisałem wcześniej, również za pomocą pętli FOR

Żeby Was nie męczyć postanow­iłem taki skrypt w BASH’u przy­go­tować. Nie jest może per­fek­cyjny, ale z pewnoś­cią speł­nia swoje przez­nacze­nie i jest wygodny w uży­ciu :) ( dla chęt­nych skrypt można ściągnąć tutaj ). Skrypt zamieszczam do wglądu poniżej, ale radzę nie kopi­ować ( albo robić to rozważnie), ponieważ mogą pow­stać nieś­cisłości wynika­jące z oper­acji kopiuj/wklej…

#!/bin/bash

TRYB=$1

#zmienne skryptu
SIEC="192.168.1.0/24" #siec lokalna, ktora ma nie meic dostepu do nizej wymienionych stron
PORT="80"
#port 80 = WWW

PRZEKIEROWANIE_NA="209.85.135.147" #ustawilem domyslne przekierowanie na strone Google
PORT_NA="80" #jak wyzej
LISTA_STRON="chomikuj.pl wrzuta.pl rapidshare.com megaupload.com" #lista oddzielona spacjami

#domyslnie nie sa wyswietlane reguly w czasie dzialania programu
VERBOSE="0"

if [ -n $2 ]; then
VERBOSE=$2
fi

case $TRYB in
"on")
if [ -n "$LISTA_STRON" ]; then
for STRONY in ${LISTA_STRON}; do
if [ "$VERBOSE" = "1" ]; then
echo $STRONY
fi
ADRESY=$(host -t a $STRONY | awk '{ printf "%s ", $4 }')

if [ -n "$ADRESY" ]; then
for STRONY_IP in ${ADRESY}; do
if [ "$VERBOSE" = "1" ]; then
echo "iptables -t nat -A PREROUTING -p tcp -s $SIEC -d $STRONY_IP --dport $PORT -j DNAT --to $PRZEKIEROWANIE_NA:$PORT_NA"
fi
iptables -t nat -A PREROUTING -p tcp -s $SIEC -d $STRONY_IP --dport $PORT -j DNAT --to $PRZEKIEROWANIE_NA:$PORT_NA
done
fi
if [ "$VERBOSE" = "1" ]; then
echo ""
fi
done
fi
;;
"info")
iptables --list PREROUTING -t nat
;;
"off")
iptables --flush PREROUTING -t nat
;;
"-h")
echo "Program przyjmuje zmienne: "
echo "-h pomoc"
echo "on wlaczenie regul"
echo "off wylaczenie regul"
echo "info informacje o regulach"
echo "0/1 w trybie 'on' ukrywanie/wyswietlanie komunikatow"
echo "usage: ./blokowanie_stron on 1"
;;

*)
echo "Nie podano zmiennej trybu. (on/off/info)"
exit
;;
esac
Return to Top ▲Return to Top ▲