I've managed to prepare Fedora 16 easy installation scripts for GitLab. Use them as root user. Download 2 scripts from bottom of this post and save them on your Linux server.

Be advised: this script is outdated. Please use it with caution! I'm working on update.

first, run this script:

gitlab_unattended_install_start.sh

execute these commands:

	cd /var/www/gitlabhq
	source /etc/profile.d/rvm.sh
	rvm all do rake db:setup
	rvm all do rake db:seed_fu
	

to finish, fire up this script, and you're done :)

gitlab_unattended_install_finish.sh

scripts download

gitlab_unattended_install_start.sh
gitlab_unattended_install_finish.sh

This is updated version of my tutorial for GitLab 2.1. Old version can be found here

GitLab is a wonderful piece of software made by these guys and I'd like to try and install it on Fedora 16 system, as it is most recent Fedora OS at the time I am writnig this. I will base my tutorial on on found here by Déja. Also on my way to successful install I've stumbled upon this description, so I might have gain some experience from it too.

GitLab is Ruby on Rails application and it takes some experience to get it all working because of many, many, many dependencies and packages it needs. It's nothing like simple PHP on Apache installation. But it works and it's worth it, I assure you :)

Let's begin! (by the way: I perform all as root user - again: test environment)

small edit: For people who only want this to work and not necessarily wish to know how and why, I have prepared easy installation scripts in here

another EDIT: GitLab is under heavy development and now it's stable version is 2.1. This means that my guide might be not entirely accurate. Please be cautious. I'll update it soon.

1. First of all: I am working on virtual machine with brand new and fresh Fedora 16 installed. Minimal installation, just to make sure nothing messes with GitLab. Consider this a test environment.
2. Once you have your OS ready, update it with yum update and also install some packages you will need on the way:

   yum install make openssh-clients gcc libxml2 libxml2-devel \
   libxslt libxslt-devel python-devel

3. Check what version of ruby is available via yum. GitLab needs at least version 1.9.2

   yum info ruby

   on mine it says that the only available version for me is 1.8.7.357 so I have to get it somewhere else.

4. Using RVM to install Ruby.
   

   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 Version Manager - brilliant tool, which you can use to install and manage your Ruby with ease. Let's check it out, shall we? (you can install Ruby any way you want - I'll just do this RVM way)

   Notice use of --with-openssl switch - without that passenger will complain about Ruby OpenSSL support and won't compile in next step.

   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 --with-openssl
   
   rvm use ruby-1.9.2-p290 --default
   

   Done. Just like that we have operational Ruby 1.9.2-p290. No RPMs, no going back in time.. nice, huh? :)

5. Good. Small (nice) surprise: our RPM installed ruby gems for us, so now we only have to get rails gem.
   first, just to make sure everything is up to date, execute:

   rvm all do gem update --system

   now install rails with:

   rvm all do gem install rails

6. Now we will install apache2 as a webserver and Passenger for ruby apps deployment. I know that most GitLab tutorials use nginx but I really like apache ;)

   yum install -y httpd

   rvm all do gem install passenger

   as I mentioned: I use apache, so I will need passenger module for it:
   first some required packages:

   yum install -y 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 information on how to proceed with apache configuration:

   • add following 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 create file named default.conf (or gitlab.conf, or something other you like) in /etc/httpd/conf.d/ containing these lines (remember 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)

7. Now it is time for gitolite. I won't use gitosis because it is not actively developed any more and I found that new GitLab works better with gitolite.install it with

   yum install -y gitolite

   now, wasn't that quick? :)

8. Now we will need to create new gitolite server configuration and in order to do that we have to generate SSH key-pair. But first things first.
   To get us started we will create git user with

   adduser -r -m --shell /bin/bash \
    --comment 'git version control' git
   mkdir /home/git/.ssh
   chown git:git -R /home/git/.ssh
   

   Now we have to create SSH keys pair for him:

   ssh-keygen -q -o -N '' -t rsa -f /home/git/.ssh/id_rsa

   To initialize Gitolite we need to first edit it's default configuration file and change default permissions and then initialize it by using git user:

   sed -i 's/0077/0007/g' /usr/share/gitolite/conf/example.gitolite.rc
   
   su - git -c "gl-setup -q /home/git/.ssh/id_rsa.pub"

   as mentioned here

9. Just to make sure that git user has all necessary access rights to his own home directory after we have added SSH keys for him:

   chown git:git -R /home/git/

10. OK, time for next requirements: python Pip, I will go with method from original post and NOT use yum for that.

    curl http://python-distribute.org/distribute_setup.py | python
    

    and then

    easy_install pip
    

11. Database. We need it. We have it already - it was installed on the way as a dependency. Just to make sure check if you have SQLite at list version 3.6 with:

    yum info sqlite

    I have 3.7.7.1. All we need is SQLite development package, get it with:

    yum install -y 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:

    rvm all do gem install bundler

    you will need one more dependency for bundle install

    yum install -y libicu-devel

    finally (remember to be in GitLab directory):

    bundle install

    (go get yourself a coffee or other treat - it takes a while)

13. Redis installation. More about Redis here

    yum install -y redis

    and start it with:

    service redis start
    

14. Preparing config files.

    copy database and gitlab config files from example to working copies:

    cp config/gitlab.yml.example config/gitlab.yml
    cp config/database.yml.example config/database.yml

15. DB setup:
    And now database 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 versions of rake installed (I had somehow): 0.8.7 and 0.9.2. If you do, remove older with:

    gem uninstall rake

    and choose appropriate version. If you still have problems try:

    gem install rake

    -> don't know why, but if it installs again same version of rake, it works.

16. Apache virtual host configuration should look something 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>
    

17. enable apache user, co you can su into this account:

    usermod -s /bin/bash -d /var/www/ apache

    prepare SSH key for him (actually use one created for git user)

    mkdir /var/www/.ssh
    
    cp -f /home/git/.ssh/id_rsa /var/www/.ssh/ && chown apache:apache /var/www/.ssh/id_rsa && chmod 600 /var/www/.ssh/id_rsa
    

    add localhost to apache user known_hosts with:

    ssh-keyscan localhost >> /var/www/.ssh/known_hosts

    also give him permissions to his own home directory with:

    chown -R apache:apache /var/www/

18. add apache user to git group with:

    usermod -a -G git apache

19. check if repositories directory has correct permissions, it should be 770. You can set it with

    chmod 770 /home/git/repositories/

20. double check your firewall (for example iptables) if it allows connections on port 80 to your server.

21. important: Apache won't be able o start with SELinux set to "enforcing". Please set it to permissive.

22. start apache server with:

    service httpd start

23. Now it all should work. Fingers crossed.. go to http://www.yourhost.com
24. Now you should be able to log in using these credentials:
    

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

    and you're in :)

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

Troubleshooting:

1. I get error 500 when I enter particular project and try to get into it's "Admin" section. Don't know how to fix it yet.To fix it, check if repositories directory has correct permissions, it should be 770. You can set it with

   chmod 770 /home/git/repositories

   also set this:

   chmod 770 /home/git

2. If Passenger insists, that we don't have or he can't see grit library (gem actually, as far as I know) even though we have it.
   

   https://github.com/gitlabhq/grit.git (at master) is not checked out. Please run `bundle install` (Bundler::GitError)

   Only resolution to this problem I have found is to (as root) change /usr/local/rvm/gems/ruby-1.9.3-p0/gems ownership to apache user with:

   chown apache:root -R /usr/local/rvm/gems/ruby-1.9.3-p0/gems

   I know that is not great resolution but it worked for me. If you'll happen to know better way - please let me know, so I can update this tutorial and my knowledge of course ;)

   Edit

   I found another solution (instead of changing permissions): after first

   bundle install

   edit Gemfile and in lines containing "git:" remove everything after first comma, for example:

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

   should be

   gem "grit"

   and so on.

   then do again

   bundle install

   and now passenger shouldn't complain any more.

This is old version of my tutorial. Most recent version can be found here

GitLab is a wonderful piece of software made by these guys and I'd like to try and install it on Fedora 16 system, as it is most recent Fedora OS at the time I am writnig this. I will base my tutorial on on found here by Déja. Also on my way to successful install I've stumbled upon this description, so I might have gain some experience from it too.

GitLab is Ruby on Rails application and it takes some experience to get it all working because of many, many, many dependencies and packages it needs. It's nothing like simple PHP on Apache installation. But it works and it's worth it, I assure you :)

Let's begin! (by the way: I perform all as root user - again: test environment)

small edit: For people who only want this to work and not necessarily wish to know how and why, I have prepared easy installation scripts in here

1. First of all: I am working on virtual machine with brand new and fresh Fedora 16 installed. Minimal installation, just to make sure nothing messes with GitLab. Consider this a test environment.
2. Once you have your OS ready, update it with yum update and also install some packages you will need on the way:

   yum install make openssh-clients gcc libxml2 libxml2-devel \
   libxslt libxslt-devel python-devel

3. Check what version of ruby is available via yum. GitLab needs at least version 1.9.2

   yum info ruby

   on mine it says that the only available version for me is 1.8.7.35 so I have to get it somewhere else.

4. Method #1.
   I will do as it says here. I have tried it before and it works flawlessly. With one or two catches of course ;)Mentioned catches and tips:
   • you need wget, if you don't have it already use

     yum install -y wget

   • other needed packages (plus few dependencies) 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 virtual machine, like me, you can first make a snapshot of it, then build ruby RPM package, copy it to you host machine (or network share or whatever place outside virtual machine) and then go back in time to you snapshot. Voila! Clean system ready for further installing GitLab. All you need to do is install earlier created ruby RPM. Anyway this is what I'm gonna do today. Keep it clean.
   • last step - your RPM will end up somewhere in ~/rpmbuilds/RPMS directory. It will reside in folder named after your system architecture, 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 minutes to compile and prepare RPM. Not so bad.
   Now I go back in time in my VM and install newly created RPM with

   rpm -Uvh ruby-1.9.2p290-2.fc16.i386.rpm

5. Method #2. ( I prefer 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 Version Manager - brilliant tool, which you can use to install and manage 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 operational Ruby 1.9.2-p290. No RPMs, bo going back in time.. nice, huh? :)

6. Good. Small (nice) surprise: our RPM installed ruby gems for us, so now we only have to get rails gem.
   first, just to make sure everything is up to date, execute:

   gem update --system

   now install rails with:

   gem install rails

7. Now we will install apache2 as a webserver and Passenger for ruby apps deployment. I know that most GitLab tutorials use nginx but I really like apache ;)

   yum install -y httpd

   gem install passenger

   as I mentioned: I use apache, so I will need passenger module 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 information on how to proceed with apache configuration:

   • add following 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 create file named default.conf (or gitlab.conf, or something other you fancy) in /etc/httpd/conf.d/ containing these lines (remember 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 gitolite. I won't use gitosis because it is not actively developed any more and I found that new GitLab works better with gitolite.install it with

   yum install -y gitolite

   now, wasn't that quick? :)

9. Now we will need to create new gitolite server configuration and in order to do that we have to generate SSH key-pair. But first things first.
   To get us started su into gitolite user with

   su - gitolite

   now try to log into localhost via SSH -> it's small thing which will make our life easier in the future.

   ssh localhost

   Just make it add localhost to list of known host - no need to actually authenticate. SSH created for us ~/.ssh directory. That's nice.SSH key generation is as easy as:

   ssh-keygen -t rsa

   use default path for saving key-pair (/var/lib/gitolite/.ssh/id_rsa) and no paraphrase. Test environment. Just a reminder.as for initialization of gitolite repository:

   gl-setup .ssh/id_rsa.pub

   next hit ENTER and edit will open, change value of

   $REPO_UMASK to 0007

   as mentioned hereLook like we are done here. Exit gitolite user shell and return to being almighty root himself ;)

10. OK, time for next requirements: python Pip, I will go with method from original post and NOT use yum for that.

    curl http://python-distribute.org/distribute_setup.py | python
    

    and then

    easy_install pip
    

11. Database. We need it. We have it already - it was installed on the way as a dependency. Just to make sure check if you have SQLite at list version 3.6 with:

    yum info sqlite

    I have 3.7.7.1. All we need is SQLite development package, 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 (remember to be in GitLab directory):

    bundle install

    (go get yourself a coffee or other treat - it takes w while)

13. DB setup:
    

    EDIT: For GitLab version 2.1 install Redis - without it rake will fail.:

    yum install redis libicu-devel
    service redis start
    

    And now database 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 versions of rake installed (I had somehow): 0.8.7 and 0.9.2. If you do, remove older with:

    gem uninstall rake

    and choose appropriate version. If you still have problems try:

    gem install rake

    -> don't know why, but if it installs again same version of rake, it works.

14. Apache virtual host configuration should look something 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 correct settings in /var/www/gitlabhq/config/gitlab.yml

    in my case:# Git Hosting 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 permissions to his own home directory with:

    chown -R apache:apache /var/www/

    (I know this kinda overrides 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 private 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 gitolite group with:

    usermod -a -G gitolite apache

19. check if repositories directory has correct permissions, it should be 770. You can set it with

    chmod 770 /var/lib/gitolite/repositories/

20. double check your firewall (for example iptables) if it allows connections on port 80 to your server.
21. start apache server with:

    service httpd start

22. Now it all should work. Fingers crossed.. go to http://www.yourhost.com
23. Now you should be able to log in using these credentials:
    

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

    and you're in :)

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

Troubleshooting:

1. I get error 500 when I enter particular project and try to get into it's "Admin" section. Don't know how to fix it yet.To fix it, check if repositories directory has correct permissions, it should be 770. You can set it with

   chmod 770 /var/lib/gitolite/repositories/

2. If Passenger insists, that we don't have or he can't see grit library (gem actually, as far as I know) even though we have it.
   

   https://github.com/gitlabhq/grit.git (at master) is not checked out. Please run `bundle 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 resolution to this problem I have found is to run bundle 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 ownership to apache user with:

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

   I know that is not great resolution but it worked for me. If you'll happen to know better way - please let me know, so I can update this tutorial and my knowledge of course ;)

   Edit

   I found another solution (instead of changing permissions): after first

   bundle install

   edit Gemfile and in lines containing "git:" remove everything 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 passenger shouldn't complain any more.

Dnsmasq jest prostym serwerem udostępniającym usługi DNS i DHCP dla sieci lokalnej ( LAN ) i jak informują jego twórcy będzie się świetnie spisywał w sieciach domowych jak również niedużych środowiskach firmowych, do mniej więcej 1000 stacji roboczych. Więcej informacji o nim na stronie autora: http://www.thekelleys.org.uk/dnsmasq/doc.html

1. Ale po co?
   Dobre pytanie. Z reguły jeśli dorobiliśmy się już sieci lokalnej w domu, to poprzestajemy na poruszaniu się po niej albo za pomocą numerów IP komputerów albo za pomocą otoczenia lokalnego Windows i nazw stacji w grupie roboczej. To drugie jest dość wygodne, ale będzie działało tylko w sieciach z systemami operacyjnymi Windows, no może również z różnymi Unix'ami czy Linux'ami, ale to z kolei wymaga konfiguracji serwera Samba, co wychodzi poza zakres tego tekstu.
   Pomyślmy teraz jak pięknie by było gdyby zamiast numerów IP każdy komputer był rozpoznawany po swojej unikalnej nazwie, zupełnie jak na przykład strony internetowe. Dotyczyłoby to też drukarek sieciowych, routerów i innych urządzeń. To właśnie da nam dnsmasq. Pozwoli znajdywać za pomocą nazw wszystkie urządzenia sieciowe pobierające numery IP automatycznie poprzez DHCP lub dopisane statycznie do konfiguracji serwera. 

   Zamiast wpisywać szukając udziału sieciowego:

   \\192.168.0.4\udzial

   Wpiszemy:
   \\nasz_serwer.domena\udzial

   Łatwiej zapamiętać, prawda? Do tego jeśli się zmieni adres maszyny identyfikowanej jako "nasz_serwer" my nawet nie musimy tego wiedzieć, bo dnsmasq i tak nas do niego bezbłędnie pokieruje.

   Skoro już wiemy po co nam takie cudo... zaczynajmy! :)

2. Instalacja
   Instalacja zależy od środowiska, w którym pracujemy, ja skupię się na środowiskach Linux, a konkretnie na dwóch najpopularniejszych systemach Fedora ( jak również Red Hat, Centos ) oraz Debian ( Ubuntu i podobne ). Do instalacji będą potrzebne uprawnienia root'a. Można albo się zalogować jako root, albo dopisać przed każdym poleceniem podawanym poniżej: sudo
   na przykład: sudo yum update
    
   • Fedora
     należy wykonać polecenia:
     yum update ( na wszelki wypadek aktualizować pakiety w systemie )
     yum install dnsmasq 

   • Debian
     należy wykonać polecenia:
     aptitude update && aptitude safe-upgrade ( na wszelki wypadek aktualizować pakiety w systemie )
     aptitude install dnsmasq
     
3. Plik konfiguracyjny nazywa się dnsmasq.conf i znajduje się w katalogu /etc
   Dodatkowo dnsmasq korzysta z pliku /etc/hosts jako źródła informacji o hostach ze zdefiniowanymi stałymi adresami IP, to znaczy nie pobieranymi przez DHCP, oraz z pliku /etc/resolv.conf - stąd otrzymuje informacje na temat serwerów DNS, z których ma korzystać.
   Jest bardzo dobrze opisany za pomocą komentarzy, więc szczegółową instrukcję pominę, natomiast skupię się na kilku opcjach, które potrzebne są na początek. 
   • domain-needed - oznacza, że dnsmasq nie będzie przekazywał dalej zapytań nie posiadających domeny w adresie
   • bogus-priv - dnsmasq nie będzie przekazywał dalej adresów w nieroutowalnych zakresach adresowych
   • interface={eth0,eth1,...}  - jeśli mamy więcej niż jeden interfejs sieciowy to tutaj możemy powiedzieć dnsmasq, że ma nasłuchiwać jedynie na nim
   • except-interface={eth0,eth1,...} tak samo jak porzednio, ale dnsmasq ma nasłuchiwać na wszystkich interfejsach oprócz podanego
   • expand-hosts - ta zmienna mówi dnsmasq, że ma dodawać nazwę naszej domeny do nazw hostów i działa w połączeniu ze zmienną domain
   • domain - informacja o nazwie naszej domeny
   • dhcp-range=192.168.0.30,192.168.0.40,24h - aktywowanie serwera DHCP i ustawienie jego zakresu przydzielanych adresów na 192.168.0.30-40 i czasu lease ( wynajmu ) na 24 godziny. Jeśli mamy dwie podsieci ( vLAN lub dwie karty sieciowe ) to możemy zdefiniować tę zmienną dwukrotnie, pod warunkiem, że dnsmasq jest skonfigurowany do nasłuchiwania na obu interfejsach
   • dhcp-host=00:11:22:33:44:55,192.168.0.36 - definicja hosta, który przy każdym połączeniu ma posiadać ten sam numer IP. Identyfikacja hosta odbywa się za pomocą adresu sprzętowego jego karty sieciowej MAC. W naszym przypadku host o adresie MAC 00:11:22:33:44:55 będzie zawsze otrzymywał adres 192.168.0.36
4. Ustawienie tych wartości pozwoli nam rozpocząć używanie dnsmasq w naszej sieci i cieszenie się nazwami zamiast adresów IP.
5. Dodatkowe informacje
   • wpisy w /etc/hosts wyglądają następująco:
     adres_IP    nazwa_hosta
     na przykład:  192.168.0.21    serwer
   • wpisy w /etc/resolv.conf mają postać:
     nameserver   adres_IP
     na przykład: nameserver 194.204.152.34
   • w przypadku błędów dnsdomainname przy restarcie usługi dnsmasq należy sprawdzić plik /etc/hosts.
     Wpis dla 127.0.0.1 powinien zawierać oprócz localhost wpis nasz_serwer.nasza_domena, na przykład:
     127.0.0.1   localhost   serwer.domena.com
     Po tym może być potrzebny restart systemu lub usług sieciowych.
   • w przypadku Fedory i podobnych w /etc/sysconfig/network powinien się znajdować wpis:
     HOSTNAME=nasz_serwer.nasza_domena.com
   • aby hosty z adresami IP zdefiniowanymi statycznie również mogły korzystać z zalet dnsmasq należy zamienić ich dotychczasowe adresy serwerów DNS na adres IP naszego serwera, na którym jest zainstalowany dnsmasq.

Coraz częściej pojawia się potrzeba konwersji działającej, statycznej strony napisanej w czystym HTML'u lub za pomocą prostych skryptów PHP, do postaci bardziej skomplikowanej, ale dającej dużo większe możliwości. Mam tutaj na myśli systemy CMS ( Content Management System ). Opiszę taką konwersję na przykładzie WordPress'a.

1. Wstęp
   Typowa statyczna strona jest napisana w HTML'u. Czasem nie jest do końca statyczna, bo ma powklejane tu i tam fragmenty kodu PHP lub JavaScript. Na potrzeby tego tutoriala przyjmę jednak, że mamy do czynienia ze stroną stworzoną za pomocą jedynie HTML'a.
   Taka strona składa się najczęściej z mniej więcej takiej struktury plików, która składa się na całość, którą od tej pory będę w skrócie nazywał template'em: 
   • index.html
   • style.css
   • katalog z grafiką, np.: img

   Plik index.html zawiera całą treść strony, wszystkie tagi HTML oraz odniesienia do lokalizacji pliku z kaskadowymi stylami ( style.css ) oraz lokalizacją grafik. To on jest dla nas najbardziej interesujący i w nim będzie się działa cała "magia" :)

2. Dla ułatwienia i lepszej wizualizacji konwersji od tej pory będę przedstawiał całą operację na konkretnym przykładzie. Proponuję użycie jako wyjściowego template'a któregoś z dostępnych na stronie Open Source Web Design ( www.oswd.org ) na przykład: LoadFoO [V2]
3. Po ściągnięciu i rozpakowaniu tego template'a widać takie pliki i katalogi:
   • css ( katalog zawierający plik style.css - definicję stylów kaskadowych )
   • img ( katalog zawierający pliki graficzne )
   • js ( katalog zawierający pliki JavaScripts )
   • favicon.ico ( plik z ikoną naszej strony pokazującą się w przeglądarce )
   • index.html ( szkielet template'u, tak jak opisywałem wcześniej )
4. CSS
   Konwencja struktury plików dla template'ów w Worpdress wymaga, aby plik style.css znajdował się w głównym katalogu, tzn tam gdzie index.html , więc przenieśmy go teraz z katalogu css o jeden poziom wyżej. Pusty obecnie katalog css można usunąć, żeby nie zaśmiecał przestrzeni. 

   Plik style.css jest jednocześnie opisem template'a, a konkretnie jego nagłówek, który wygląda np tak:

   /* Theme Name: nazwa_template'a Theme URI: ścieżka URI Description: Opis Version: wersja, np: 1.0 Author: twoje_imię Author URI: twój adres WWW */

   Umieść ten nagłówek przed wszystkimi definicjami stylów w style.css.

   W naszym przypadku pamiętaj o zmianie ścieżek w pliku css, aby wskazywały na katalog img. Teraz jest to na przykład: ../img/jakis_plik.jpg trzeba je wszystkie zmienić na img/jakis_plik.jpg ( przez usunięcie ../ )

5. Opcjonalnie, ale zalecałbym to, można stworzyć obraz - miniaturę template'a. Powinien mieć rozmiar 300x225 pikseli oraz format PNG. Nazwa musi brzmieć: screenshot.png i musi byc umieszczony tam gdzie plik style.css.
6. Cięcie/Gięcie
   Głównym plikiem naszego template'a jest index.php, ale skąd go wziąć? Zmienić rozszerzenie pliku index.html na php
   To jednak nie wystarczy. Trzeba go teraz odrobinę pociąć na kawałki, w najprostszym wypadku będą to pliki:
   header.php - plik zawierający definicje nagłówka strony
   footer.php - plik zawierający stopkę strony
   my dodamy jeszcze sidebar.php 

   Nazwy tych plików są ważne, ponieważ dzięki temu WordPress sam znajdzie te pliki, bez potrzeby ich definiowania. W kolejnych punktach opiszę każdy z nich.

   Plik index.php zawiera jeszcze definicje tak zwanego "loop" czyli takiej "karuzeli", która pokazuje odpowiednie posty/wpisy na stronie głównej. O tym również później.

7. header.php
   Najpierw przykładowy plik header.php: 

   <html <?php language_attributes(); ?>> <head> <meta charset="<?php bloginfo( 'charset' ); ?>" /> <title><?phpglobal $page, $paged;   wp_title( '|', true, 'right' );   bloginfo( 'name' );   $site_description = get_bloginfo( 'description', 'display' ); if ( $site_description &amp;&amp; ( is_home() || is_front_page() ) ) echo " | $site_description";   if ( $paged >= 2 || $page >= 2 ) echo ' | ' . sprintf( __( 'Page %s', 'twentyten' ), max( $paged, $page ) );   ?></title> <link rel="profile" href="http://gmpg.org/xfn/11" /> <link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_url' ); ?>" /> <link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" /> <?php   if ( is_singular() &amp;&amp; get_option( 'thread_comments' ) ) wp_enqueue_script( 'comment-reply' );   wp_head(); ?> </head>   <body <?php body_class(); ?>>

   Jest on pełny znaczników w języku PHP, które rozpoznaje WordPress po czym wypełnia je zawartością dynamiczną, np:

   opisuje lokalizację pliku style.css ( nie definiujemy nazwy, bo jest on domyślny dla WordPress'a )

   wp_head(); powoduje wyświetlenie nagłówka HTML na stronie
   pozostałe zmienne są w większości przypadków dość jasno opisane przez swoje nazwy.

8. footer.php
   Przykładowa zawartość pliku footer.php:

   <div id="foot"> </div> </div> <?php wp_footer(); ?> </body> </html>&nbsp;

   Zawiera on przeważnie definicję stopki zawartej jako jakiś element

   oraz wywołanie PHP: wp_footer(); - zawiera ono w sobie zmienne potrzebne przez wiele wtyczek WordPress'a, głównie odnoszące się do kodu JavaScript.

9. sidebar.php
   W nim umieścimy zawartość prawej kolumny naszego template'a, czyli w naszym przypadku trzeba wyciąć następujący kod z index.php i wkleić do sidebar.php:

   <ul id="nav"> <li><a href="#Home">Home</a></li> <li><a href="#Archive">Archive</a></li> <li><a href="#Link">Links</a></li> <li><a href="#download">Download</a></li> <li><a href="#support">Support</a></li> <li><a href="#contact">Contact</a></li> </ul> <div> <h2 style="margin-top:17px">Recent Entries</h2> <ul> <li><a href="#">Recent Entries1</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries2</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries3</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries4</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries5</a> <i>01 Des 06</i></li> </ul> </div>

10. index.php
    I znowu wracamy do głównego pliku naszego template'a: index.php. Zawiera on w sobie całą resztę kodu naszej strony, oczywiście po wycięciu z niego tych fragmentów, które zawarte są w pozostałych plikach PHP. 

    Nagłówek będzie zdefiniowany w header.php, a więc z index.php można usunąć wszystko od samej góry do znacznika z nim włącznie. Zamiast tego co wytniemy trzeba wstawić:

    <?php get_header(); ?>

    Kod prawej kolumny już przenieśliśmy do sidebar.php, teraz jest puste miejsce pomiędzy

    <div id="right"> i </div>

    . Trzeba je wypełnić kodem PHP wordpress:

    <?php get_sidebar(); ?>

    Stopkę strony utworzymy poprzez usunięcie wszystkiego poczynając od 

    <div id="foot">

    do końca i zastąpienie przez:

    <?php get_footer(); ?>

    Teraz po otworzeniu panelu sterowania naszej strony WordPress i wejściu w menu Motywy zobaczymy nowy motyw o nazwie jaką mu nadaliśmy, po jego aktywacji zobaczymy nowy template w akcji. Na razie jednak nie wszystko działa tak jak powinno. Na przykład menu, o tym za chwilę.

11. Menu stron.
    W pliku index.php zmień kod pomiędzy:

    <div id="menu"><ul> i </ul></div>

    na kod PHP WordPress: 

    <?php wp_list_pages('sort_column=menu_order&amp;title_li='); ?>

    W tym przypadku dodałem zmienną sort_column=menu_order aby menu korzystało z kolejności jaką mu narzucimy w panelu sterowania oraz title_li= ( puste), ponieważ nie chcemy aby pokazywał się tytuł "Menu Główne".

    Po odświeżeniu strony zobaczymy już Główne menu zawierające pozycje zdefiniowane przez nas w panelu administracyjnym. Reszta na razie nie jest jeszcze aktywna.

12. Dodatkowe menu w panelu bocznym.
    Dodanie drugiego menu pozwoli na stworzenie drugiego menu, zawierającego inne elementy niż głowne. Najpierw należy stworzyć plik functions.php o zawartości: 

    <?php add_theme_support( 'menus' ); ?>

    co doda pozycję "Menu" w dziale "Wygląd" w panelu administracyjnym, w którym to miejscu będzie można zdefiniować i dodać kolejne menu do naszej strony.

    W sidebar.php zamień kod:

    <li><a href="#Home">Home</a></li> <li><a href="#Archive">Archive</a></li> <li><a href="#Link">Links</a></li> <li><a href="#download">Download</a></li> <li><a href="#support">Support</a></li> <li><a href="#contact">Contact</a></li>

    na:

    <?php wp_nav_menu( array( 'sort_column' => 'menu_order') ); ?>

    gdzie sort_column wymusza kolejność w menu taką jak w panelu administracyjnym.

    Dodatkowo, żeby wszystko się tak samo wyświetlało dodaj do style.css następującą linijkę:

    #nav ul {list-style-type:none;list-style-image:none;}

    gdzieś w okolicy definicji #nav

    Po dodaniu elementów z poziomu panelu pojawią się one w wybranym przez nas miejscu w panelu bocznym.

13. Panel boczny po raz drugi: box
    W dolnej części panelu bocznego znajduje się box zawierający linki do ostatnich wpisów, aby go zrealizować dynamicznie zamień kod: 

    <div class="box"> <h2 style="margin-top:17px">Recent Entries</h2> <ul> <li><a href="#">Recent Entries1</a> <i>01 Des 06</i></li>   <li><a href="#">Recent Entries2</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries3</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries4</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries5</a> <i>01 Des 06</i></li>   </ul> </div>

    na:

    <div class="box"> <h2 style="margin-top:17px">Recent Entries</h2> <ul> <?php global $post; $args = array( 'numberposts' => 5, 'offset'=> 0, 'orderby'=>'post_date'); $myposts = get_posts( $args ); foreach( $myposts as $post ) : setup_postdata($post); ?> <li><a href="<?php the_permalink(); ?>"><?php the_title(); ?> </a> <i> <?php the_date(); ?></i></li> <?php endforeach; ?> </ul> </div>

    To spowoduje wyświetlenie linków do 5-ciu ostatnich postów, w kolejności chronologicznej ich publikacji.

14. Loop
    Jest to taka karuzela, czyli sposób w jaki wyświetlane są posty na głównej stronie, jeśli nie jest ona statyczna.
    Przykładowy kod, jaki użyję w tym template'cie:
    zamiast: 

    <div id="left"> <h2>Welcome to LoadFoO [V1]</h2> <p>Text Content Text <a href="#">Content Text</a> Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content.</p> <ul> <li>ul-li test.</li>   <li>ul-li test.</li> <li>ul-li test.</li> <li>ul-li test.</li> <li>ul-li test.</li> </ul> <h2>Functionality or performance</h2>   <p>Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content. </p> </div>

    użyj:

    <div id="left"> <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?> <h2><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></h2> <p> <?php the_content(); ?></p> <?php endwhile; else: ?> <p>Brak postów.</p> <?php endif; ?> </div>

15. Szablon wpisu
    Musimy jeszcze zdefiniować szablon wpisu ( Post ), a robi się to w pliku:
16. Drobne poprawki.
    a) W przypadku tego tematu postanowiłem usunąć kod odpowiadający za powiększanie/pomniejszanie tekstu: 

    <div style="float: right;"><a href="javascript:ts('body',1)">[+]</a> | <a href="javascript:ts('body',-1)">[-]</a></div>

    b) dodanie tytułu strony w górnej części poprzez zamianę w index.php:

    LoadFoO [V2]

    na:

    <?php bloginfo( 'name' ); ?>

    c) mała zmiana w style.css aby nagłówki wpisów wyglądały tak jak w oryginale:

    dodaj:

    h2 a {color: #9F9F9F; text-decoration: none; }

    To by było na tyle, no przynajmniej na początek. Teraz cały dalszy rozwój i życie template'a zależy od Ciebie drogi czytelniku :)

Czasem pojawia się potrzeba wyświetlenia zadań Cron wszystkich użytkowników w systemie.

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

A dla konkretnego użytkownika można zastosować polecenie:

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

gdzie, USER = nazwa szukanego użytkownika

Squid ( http://www.squid-cache.org ) jest oprogramowaniem umożliwiającym filtrowanie ruchu sieciowego, ale nie był to początkowy zamysł jego twórców. Z założenia Squid miał umożliwić tworzenie pamięci podręcznej treści ( grafik itp. ) pobieranych z Internetu przez użytkowników w czasie serfowania po nim.

Jedną z możliwości oferowanych przez Squid jest filtrowanie stron jakie moga odwiedzać użytkownicy znajdujący się w naszej sieci.

Więc po kolei :)

Zwyczajowo, to znaczy domyślnie, Squid korzysta z portu 3128, ale na nasze potrzeby to nie jest wystarczające. Dlaczego? Oznacza to, że jak już wszystko skonfigurujemy, ustawimy i będzie działało to i tak niewiele nam po tym, bo użytkownicy naszej sieci będą musieli dobrowolnie ustawić w swoich przeglądarkach ustawienia adresu naszego serwera Squid oraz portu. Przyznam szczerze, że jakoś nie widzę u nich zachwytu, kiedy zorientują się, że owocuje to niczym więcej poza ograniczeniami nałożonymi przez nas. I tutaj nadchodzi czas na wytłumaczenie drugiego słowa z tytułu niniejszego artykułu: transparent. Jest to magiczne słowo oznaczające "przezroczysty". Co to oznacza dla nas? W największym uproszczeniu cały ruch sieciowy WWW zostanie domyślnie przekierowany tak, aby przechodził przez nasz serwer proxy Squid i to w dodatku bez potrzeby żadnej konfiguracji po stronie użytkowników, a co więcej - nie będą mogli nic na to poradzić :)

Oczywiście można ustawić proxy korzystając wyłącznie z domyślnego trybu Squid'a i wymusić na użytkownikach korzystanie z niego ( czyli przymus konfiguracji przeglądarki ) na zasadzie: nie skonfigurujesz - nie masz dostępu do stron WWW. Uważam, że takie rozwiązanie jest nieeleganckie i dużo bardziej kłopotliwe w praktyce. O wiele łatwiej sterować dostępem centralnie, na naszym serwerze, w konfiguracji Squid'a.

Po tym przydługim wstępie zabieramy się do pracy :)

1. Usługę Squid proxy stawiamy najlepiej na serwerze pełniącym rolę bramy ( ang. Gateway ) ale nie koniecznie. Na potrzeby tego artykułu przyjmę, że będzie ona zainstalowana właśnie na serwerze - bramie. Dodam, że

2. Instalacja odbywa się w sposób standardowy, z paczek binarnych właściwych dla naszej dystrybucji Linux'a lub ewentualnie ( czego osobiście nie praktykuję ) dla Windows'a. Instalacja opisana jest dokładnie tutaj i nie wchodzi w zakres tego artykułu, chyba, że zaistnieje taka potrzeba, żeby go o te informacje wzbogacić.

3. Konfiguracja usługi Squid odbywa się poprzez edycje pliku /etc/squid/squid.conf ( dla Debian'a, lub analogicznie w przypadku innych dystrybucji Linux'a ).

UWAGA: opcje są wczytywane po kolei od początku pliku konfiguracyjnego do końca!

Jest to ważne, ponieważ można się łatwo pogubić i doszukiwać przyczyny nie działania zdefiniowanych przez nas filtrów, ale to wyjdzie w praktyce.

Najpierw należy definiować zasady szczegółowe, a potem ogólne, ponieważ Squid bierze pod uwagę pierwszą regułę jaką napotka i nie szuka dalej, więc jeśli najpierw umieścimy pozwolenie na dostęp dla wszystkich, a potem zasady szczegółowe, to zostaną one zignorowane, ponieważ Squid "zadowoli" się regułką ogólną, którą napotkał wcześniej w pliku konfiguracyjnym.

4. Pierwszą 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 filtrowany 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 pozwoli wszystkim komputerom w naszej sieci na korzystanie ze Squid'a. To nie do końca jest nasz cel, ponieważ na tym etapie konfiguracji wszystko będzie śmigało bez żadnych ograniczeń w tę i z powrotem bez żadnej kontroli.

5. Teraz pora na kilka ograniczeń :)

Najlepiej ustawiać ograniczenia za pomocą odpowiednich plików konfiguracyjnych z listami domen WWW, np:

domeny zabronione: /etc/squid/domeny_zabronione

domeny w tym pliku umieszczamy po jednej w każdej linijce.

w pliku konfiguracyjnym Squid przed ( czyli wyżej, jak kto woli ) poprzednimi wpisami definiującymi dostęp dla całej sieci, dodajemy linijki:

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

to spowoduje, że żaden komputer w naszej sieci nie będzie mógł otworzyć stron zdefiniowanych w tym pliku.

6. A teraz troszkę dokładniejszej konfiguracji :)

Załóżmy, że mamy w sieci jakiś komputer, 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ż poprzednia 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ż :)

przypominam jeszcze raz o kolejności wpisów w pliku konfiguracyjnym Squid'a.

7. Ostatnie szlify ( prawie )

Aby sprawić by Squid zachowywał się jako transparent, 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 serwera, na którym zainstalowany jest Squid

8. Teraz już naprawdę ostatnie ustawienia :)

Pozostało ustawienie reguły iptables, tak aby kierowała cały ruch z portu 80 i 443, domyślnych dla stron WWW, na port 3128 Squid'a.

W moim przypadku trzeba skonfigurować ShoreWall, który zarządza regułami iptables:
w /etc/shorewall/rules

ACCEPT	$FW	net	tcp	www
REDIRECT	loc	3128	tcp	www

w przypadku 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 analogicznie dla innych dystrybucji )

Dzisiaj zajmiemy się kwestią czasem bardzo potrzebną, to znaczy blokowaniem użytkownikom sieci lokalnej dostępu do konkretnych serwisów internetowych. Chodzi o sytuację, kiedy chcemy zablokować możliwość "wchodzenia" tylko na niektóre strony a nie odwrotnie, to znaczy zezwolić tylko na niektóre, a zablokować domyślnie wszystkie.

Dodatkowym założeniem naszego projektu będzie to, że ruch zostanie przekierowany i użytkownik zamiast trafić na stronę typu chomikuj.pl trafi na inną, zdefiniowaną przez nas, np. google.pl lub naszą stronę firmową.

Można to osiągnąć za pomocą tablicy 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 działania naszej regułki

Wszystko pięknie i w ogóle, ale jak to zrobić jeśli adres, np rapidshare.com ma więcej niż jeden adres IP? tutaj z pomocą przychodzi 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 występują ). Czyni tę magię za pomocą polecenia host -t a NAZWA_DOMENY oraz pętli FOR
2. dla każdego odnalezionego adresu stosuje regułkę, którą opisałem wcześniej, również za pomocą pętli FOR

Żeby Was nie męczyć postanowiłem taki skrypt w BASH'u przygotować. Nie jest może perfekcyjny, ale z pewnością spełnia swoje przeznaczenie i jest wygodny w użyciu :) ( dla chętnych skrypt można ściągnąć tutaj ). Skrypt zamieszczam do wglądu poniżej, ale radzę nie kopiować ( albo robić to rozważnie), ponieważ mogą powstać nieścisłości wynikające z operacji kopiuj/wklej...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

#!/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

Windows 7 ma często kłopoty z połączeniem z udziałami Samby na serwerze z zainstalowanym Linux'em i nie pozwala nam się zalogować do udziału Samby ( lub np. mapować dysku sieciowego ).

Aby temu zaradzić należy ustawić dwie opcje ( jako użytkownik z uprawnieniami administratora ):

• Panel Sterowanie \ Narzędzia administracyjne \ Zasady Zabezpieczeń Lokalnych i następnie: Zasady Lokalne -> Opcje Zabezpieczeń -> Zabezpieczenia Sieci: poziom uwierzytelniania LAN Manager i opcja: Wyślij odpowiedzi LM i NTLM
• Panel Sterowanie \ Narzędzia administracyjne \ Zasady Zabezpieczeń Lokalnych i następnie: Zasady Lokalne -> Opcje Zabezpieczeń -> Zabezpieczenia Sieci:minimalne zabezpieczenie sesji dla klientów opartych na NTLM SSP i odznaczyć opcję: Wymagaj szyfrowania 128-bitowego
• Panel Sterowanie \ Narzędzia administracyjne \ Zasady Zabezpieczeń Lokalnych i następnie: Zasady Lokalne -> Opcje Zabezpieczeń -> Zabezpieczenia Sieci:minimalne zabezpieczenie sesji dla serwerów opartych na NTLM SSP i odznaczyć opcję: Wymagaj szyfrowania 128-bitowego

To powinno umożliwić pełną współpracę serwera Samba z systemem Windows 7

Mapowanie dysku sieciowego odbywa się przez adres: \\nazwa_serwera\nazwa_udzialu i następnie poprzez podanie nazwy użytkownika i hasła.

Jeśli jednak nadal nie działa to sprawdź czy wszystko masz ustawione wg. tego schematu:

Przypuśćmy, że mamy taki udział zdefiniowany w Sambie:


[nazwa_udzialu]
path = /sciezka/do/udzialu
comment = komentarz
available = yes
browseable = yes
public = no
writable = yes
valid users = samba-user
write list = samba-user
read list = samba-user


Użytkownicy systemu Windows 7 będą widzieli ten udział, ale nie będą mogli się z nim połączyć pomimo podawania hasła. W takiej sytuacji należy sprawdzić kilka zmiennych w pliku smb.conf:

1. czy jest ustawiona opcja uwierzytelniania poprzez użytkowników a nie udziały, tzn:
   security = user
   edit: powinno działać również jako security = share, ale polecam ten tryb tylko w przypadku chęci udostępniania udziału publicznego z dostępem dla wszystkich
2. czy jest ustawiona opcja dotycząca szyfrowania haseł:
   encrypt passwords = true
3. czy jest ustawiona opcja przechowywania danych o użytkownikach:
   passdb backend = tdbsam
   ( może być również opcja przechowywania tych danych w pliku /etc/samba/smbpasswd, ale jej nie polecam )
4. oraz czy ustawiona jest opcja synchronizacji haseł Samby z hasłami systemowymi:
   unix password sync = yes

Oczywiście ważne jest aby połączeń z serwerem Samba nie blokował ani firewall zainstalowany w tym serwerze ( np. iptables ) ani firewall w systemie Windows 7 ( wbudowany, lub oprogramowanie zewnętrzne ).

Dodawanie użytkowników do Samby jest proste, trzeba tylko pamiętać, że użytkownik Samba musi najpierw istnieć w systemie, ale jeśli ma dostęp tylko do udziałów samby to nie musi mieć swojego katalogu domowego ani dostępu do powłoki.

1. z poziomu powłoki systemowej ( jako root lub przez polecenia su/sudo ) należy wpisać:
   smbpasswd -a nazwa_użytkownika
   , a następnie podać ( i powtórzyć ) hasło, tylko należy pamiętać, aby było ono takie samo jak hasło tego użytkownika w systemie ( serwerze, na którym znajduje się Samba )
2. drugim krokiem jest aktywacja użytkownika w Sambie poprzez polecenie:
   smbpasswd -e nazwa_użytkownika
3. przeładowanie ustawień Samby przez polecenie:
   /etc/init.d/samba reload
   lub inne polecenie służące do zarządzania usługami systemowymi, np. service samba restart
4. usuwanie użytkowników odbywa się za pomocą polecenia:
   smbpasswd -x nazwa_użytkownika

Można zobaczyć listę użytkowników dodanych do Samby poprzez polecenie:
pdbedit -w -L
lub jeśli używamy pliku /etc/samba/smbpasswd - poprzez jego edycję/podgląd.

Postanowiłem spróbować szczęścia z Symfony na moim serwerze z systemem Debian Linux, ale okazało się, że to nie jest takie proste. Stąd pomysł, żeby to opisać dla potomnych :)

Założenie: używam Symfony w wersji 1.2 oraz ORM Doctrine a nie Propel

1. najpierw trzeba ściągnąć cały framework ze strony Symfony na swój serwer ( lub tak do, którego masz dostęp z poziomu powłoki ), a następnie:

a) stwórz katalog z nazwą swojego projektu, a następnie w nim stwórz katalog lib/vendor, czyli:

mkdir -p NAZWA_PROJEKTU/lib/vendor

b) rozpakuj plik tgz za pomocą poleceń:

cd lib/vendor
tar zxpf symfony-1.2.9.tgz
mv symfony-1.2.9 symfony
rm symfony-1.2.9.tgz

2. teraz czas sprawdzić, czy mamy zainstalowane całe oprogramowanie wymagane przez Symfony:

cd ../..
php lib/vendor/symfony/data/bin/check_configuration.php

3. i tutaj zaczęły się problemy.

zmiany w php.ini to nie problem, ale trzeba pamiętać, że ( tak jak skrypt nas uprzedza ) plik php.ini, który jest sprawdzany przez skrypt może nie być tym samym plikiem, który "obsługuje" serwer WWW - u mnie właśnie tak było.

Większy problem pojawił się w momencie kiedy chciałem zająć się instalacją PDO, a dokładniej jak chciałem sobie poradzić z komunikatem o braku sterowników do rzeczonego PDO. Potrzebowałem sterownik do mysql, ale szukając przez aptitude nic nie udało mi się znaleźć w pakietach Debian'a. Wyjściem okazało się użycie systemu instalacji dodatków do PHP: pecl.

a) aby z niego skorzystać najpierw należy wykonać polecenie ( jako root ):


aptitude install php-pear

b) a potem zainstalować PDO wraz ze sterownikami do np mysql, lub innymi dostępnymi:

pecl install pdo
pecl install pdo_mysql
pecl install pdo_sqlite

c) potem pozostaje tylko dodanie odpowiednich wpisów do php.ini lub jak w moim przypadku do /etc/php5/pdo.ini:

extension=pdo.so
extension=pdo_mysql.so
extension=pdo_sqlite.so

d) i na koniec restart serwera WWW, np:

/etc/init.d/apache2 restart

To u mnie zadziałało bez problemu z wyjątkiem jednego błędu przy kompilacji pdo_mysql. W trakcie przeprowadzania sprawdzania przed kompilacją okazało się, że nie mam mysql_config i bez tego nie da rady przejść dalej. Aby to naprawić trzeba zainstalować jedną paczkę przez aptitude:

aptitude install libmysqlclient15-dev

i sprawa załatwiona.

Potem dopiero się dowiedziałem, że istnieje o wiele prostszy sposób na instalacje brakujących sterowników do PDO:

aptitude install php5-common php5-mysql php5-sqlite

a samo PDO jest zawarte w pakiecie php5-common

I to by było na tyle: Symfony jest zainstalowane i gotowe do stworzenia aplikacji w tym framework'u.