wasil.org

23gru/111

GitLab quick installation script – Fedora 16

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

Zakres tematyczny: wszystkie wpisy 1 Komentarz

20gru/1135

GitLab installation on Fedora 16 (with gitolite)

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.

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.
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
```
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.
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? :)
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
```
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)
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? :)
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
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/
```
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
```
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
```
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)
Redis installation. More about Redis here
```
yum install -y redis
```
and start it with:
```
service redis start
```

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

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.

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>

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/

add apache user to git group with:
```
usermod -a -G git apache
```
check if repositories directory has correct permissions, it should be 770. You can set it with
```
chmod 770 /home/git/repositories/
```
double check your firewall (for example iptables) if it allows connections on port 80 to your server.
important: Apache won't be able o start with SELinux set to "enforcing". Please set it to permissive.
start apache server with:
```
service httpd start
```
Now it all should work. Fingers crossed.. go to http://www.yourhost.com
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:

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
```
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.

Tagged as: Fedora, git, php, strony www 35 Komentarze

19sie/110

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

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

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

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.
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
```
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.
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
```
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? :)
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
```
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)
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? :)
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 ;)
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
```
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
```
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)
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.

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>

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

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...)
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
```
add apache user to gitolite group with:
```
usermod -a -G gitolite apache
```
check if repositories directory has correct permissions, it should be 770. You can set it with
```
chmod 770 /var/lib/gitolite/repositories/
```
double check your firewall (for example iptables) if it allows connections on port 80 to your server.
start apache server with:
```
service httpd start
```
Now it all should work. Fingers crossed.. go to http://www.yourhost.com
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:

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/
```
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.

Tagged as: git, Linux Brak komentarzy

14maj/110

dnsmasq – serwer DNS i DHCP

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

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! :)
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
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
Ustawienie tych wartości pozwoli nam rozpocząć używanie dnsmasq w naszej sieci i cieszenie się nazwami zamiast adresów IP.
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.

Tagged as: Debian, Fedora, Linux Brak komentarzy

24kwi/111

Konwersja statycznej strony HTML do WordPress

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.

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" :)
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]
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 )
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 ../ )
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.
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.

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.

footer.php
Przykładowa zawartość pliku footer.php:
<div id="foot"> </div> </div> <?php wp_footer(); ?> </body> </html> 
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.

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>

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ę.
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&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.

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.

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.

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>

Szablon wpisu
Musimy jeszcze zdefiniować szablon wpisu ( Post ), a robi się to w pliku:
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 :)

Tagged as: php, strony www 1 Komentarz

20cze/100

Zadania Cron wszystkich użytkowników

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

Tagged as: cron, Linux Brak komentarzy

20cze/100

Squid transparent proxy

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 )

Tagged as: iptables, Linux, squid Brak komentarzy

29gru/093

iptables i blokowanie stron WWW

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:

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
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...

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

Tagged as: iptables, Linux, strony www 3 Komentarze

6gru/0913

Samba i Windows 7

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:

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
czy jest ustawiona opcja dotycząca szyfrowania haseł:
encrypt passwords = true
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 )
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.

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 )
drugim krokiem jest aktywacja użytkownika w Sambie poprzez polecenie:
smbpasswd -e nazwa_użytkownika
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
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.

Tagged as: Debian, Linux, Samba, Windows 7 13 Komentarze

8lis/090

Instalacja Symfony Framework – Debian

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.

Tagged as: Debian, Linux, php, symfony Brak komentarzy

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

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

first, run this script:

execute these commands:

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

scripts download

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

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.

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.

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

Troubleshooting:

Edit

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

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

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.

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

Troubleshooting:

Edit

tagi

Panel