Gentoo Linux сборник статей


PostgreSQL database setup



Pdf просмотр
страница51/79
Дата14.11.2016
Размер5.55 Mb.
Просмотров11583
Скачиваний1
1   ...   47   48   49   50   51   52   53   54   ...   79
PostgreSQL database setup
Now that PostgreSQL is setup, it's a good idea at this point to verify the installation.
First, make sure the service starts up ok:
Code Listing 2.3: Starting up the PostgreSQL service
# /etc/init.d/postgresql start
* Starting PostgreSQL ... [ ok ]
Once this is verified working, it's also a good idea to add it to the default runlevel so it starts at boot:
Code Listing 2.4: Adding to the default runlevel
# rc-update add postgresql default
* postgresql added to runlevel default
Now that the service has started, it's time to try setting up a test database. To start out, let's create a test database by using the createdb command. We'll also pass along the -
U option to set the user (it defaults to the current user name if you don't), and the -W option to request the password we created earlier. Finally we give it the name of the database we want to create:
Code Listing 2.5: Creating a database with createdb
$ createdb -U postgres -W test
Password:
CREATE DATABASE
The database was successfully created, and we can confirm that the database can run basic tasks. We'll go ahead and drop this database (remove it) with the dropdb command:
Code Listing 2.6: Dropping a database with dropdb
$ dropdb -U postgres -W test
Password:
DROP DATABASE
Right now, only the postgres user can run commands. Obviously this is not the sort of setup one would like in a multi-user environment. The next section will look at working with user accounts.
Setting up database user accounts
As mentioned earlier, having to login as the postgres user is somewhat undesirable in a mult-user environment. In most cases there will be various users and services accessing the server, and each have different permission requirements. So, to handle this, the createuser command can be used. This command is an alternative to running a few SQL queries, and is a lot more flexible from an admin standpoint. We'll go ahead and create two users, a 'superuser' that can add other users and administer the db, and a standard user:
602

Gentoo и СУБД
Code Listing 2.7: Setting up the superuser
(replace chris with the username you'd like to use)
$ createuser -a -d -P -E -U postgres -W chris
Enter password for new user:
Enter it again:
Password:
CREATE USER
There, we've created the superuser. The command line option -a specifies that this user can add other users. -d means that this user can create databases. -P let's you enter a password for the user and -E will encrypt it for security purposes. Now then, we'll test this new user's permissions out by setting up our standard user:
Code Listing 2.8: Setting up the standard user
(replace chris with the username you've just created)
$ createuser -A -D -P -E -U chris -W testuser
Enter password for new user:
Enter it again:
Password:
CREATE USER
Success! Our new user was created using the previously created superuser. The -A and
-D options do the opposite of -a and -d, and instead deny the user the ability to create other users and databases. Now that there are users to work with, the next chapter will look at using the new database.
3. Using PostgreSQL
Setting up permissions
Now there is a user that can create databases and add other users, and the main postgres user that can do anything. The user created earlier can currently login to the server, and that's about it. In general, users need to be able to insert data and retrieve data, and sometimes any other number of tasks. So, for this new user to be able to do anything, they must be setup with the proper permissions. This can easily be done by passing the -O parameter to createdb. We'll start by making a new database, MyDB
with our superuser that will be owned by the previous testuser:
Code Listing 3.1: Creating the MyDB database
$ createdb -O testuser -U chris -W MyDB
Password:
CREATE DATABASE
Alright, now we have a new MyDB database, and a testuser that can access it. To test this out, we'll login as the testuser to the new MyDB database. We'll do this with the psql program. This program is what's used to connect to the PostgreSQL database from command line. So connect to the new database like so:
Code Listing 3.2: Logging into the MyDB database as the testuser
$ psql -U testuser -W MyDB
Password:
Welcome to psql 8.0.4, the PostgreSQL interactive terminal.
603

Gentoo и СУБД
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
MyDB=>
So, the testuser is now logged into the database, and can begin to initiate some commands. To get a feel for using PostgreSQL, the next section will take a look at some of the basic commands in navigating the psql client.
Basic PostgreSQL commands and creating a table
For those who are used to MySQL, this is somewhat of a definite read. This is where
PostgreSQL may get somewhat unique with regards to running commands. To start, here is a list of some commands that will be discussed:
Command
Usage
MySQL Equivalent
\ c [ o n n e c t ]
[ D B N A M E | -
[USER]]
Connects to another database
USE DATABASE
\q
Quit the psql client quit
\i FILE
Run commands from FILE source FILE
\o [FILE]
Send query results to FILE
INTO OUTFILE, but outputs everything (not just SELECTS)
\d [NAME]
Describe a database or table (as well as other items)
DESC(RIBE)
\db [PATTERN]
List available tables that match
PATTERN (all if no pattern is given)
SHOW TABLES
With the exception of \c[onnect], all the commands shown will be used later on in the section. So right now the database is empty. That said, we need to insert some data.
The first step to inserting data, however, is to put it in a table. Right now there are no tables in the database, so we need to create one. This is done with the CREATE
TABLE command. We'll make a table of items. They will contain a Product ID,
Description, and price:
Code Listing 3.3: Creating the products table
MyDB=> CREATE TABLE products (
MyDB(> product_id SERIAL,
MyDB(> description TEXT,
MyDB(> price DECIMAL
MyDB(> );
NOTICE: CREATE TABLE will create implicit sequence "products_product_id_seq"
for serial column "products.product_id"
CREATE TABLE
You can ignore the NOTICE, it's perfectly harmless. Looking at the last line of the function, CREATE TABLE seems to indicate that the command has succeeded.
However, let's go ahead and verify that the table was indeed successfully created with the \d command:
604

Gentoo и СУБД
Code Listing 3.4: Looking at the newly created table
MyDB=> \d products
Table "public.products"
Column | Type | Modifiers
-------------+---------
+------------------------------------------------------------------ product_id | integer | not null default nextval('public.products_product_id_seq'::text)
description | text |
price | numeric |
Indeed the table was successfully created. Now that the table is created, it needs to be populated with data. The next section will look at populating the database with data.
Inserting data into the database
This section will look at the two ways of populating the newly created table with data.
First let's look at the most basic command, INSERT:
Code Listing 3.5: INSERT syntax
INSERT INTO [tablename] (column1,column2,column3) VALUES(value1,value2,value3)
tablename contains the name of the table to insert the data into.
(column1,column2,column3) lets you specify the specific columns to insert the values into. VALUES(value1,value2,value3) is the listing of values. The values are inserted into the same order as the columns (column1 gets value1, column2 gets value2, column3 gets value3). These counts must be the same. So let's go ahead and insert an item into the table:
Important: From working with databases for a long time, I personally recommend specifying INSERT statements exactly as above. Developers often make the mistake of using INSERT INTO without specifying columns. This is unproductive, as if a new column gets added to the database, it will cause in error if the value to column count is not the same. You should always specify the columns unless you're 300% sure you'll never add a column.
Code Listing 3.6: Inserting data into the table
MyDB=> INSERT INTO products (description,price) VALUES('A test product',
12.00);
INSERT 17273 1
The last line needs a bit of explaining. The return of an insert command is an OID
(Object Identifier) and the number of rows inserted. OID's are a bit beyond the scope of this guide, and the
PostgreSQL manual has some good information on it. Now, for a situation where you have 20,000 products, these insert statements can be a little tedious. However, not all is lost. The COPY command can be used to insert data into a table from a file or stdin. In this example, let's assume that you have a csv (comma separated values) file, which contains the product id, description, and price. The file looks like this:
Code Listing 3.7: products.csv
2,meat,6.79 3,soup,0.69 605

Gentoo и СУБД
4,soda,1.79
Now we'll use the COPY command to populate our data:
Important: The COPY FROM STDIN command is used because only the postgres user can insert data from a file (for obvious security reasons).
Code Listing 3.8: Using COPY to populate the products table
MyDB=> COPY products FROM STDIN WITH DELIMITER AS ',';
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> 2,meat,6.79
>> 3,soup,0.69
>> 4,soda,1.79
>> \.
Unfortunately, this line doesn't return the same status information as the INSERT INTO statement. How do we know the data was inserted? The next section will look at running queries to check our data.
Using PostgreSQL queries
This section will look at using the SELECT statement to view data in our tables. The basic SELECT format looks like this:
Code Listing 3.9: SELECT syntax
SELECT (column1,column2|*) FROM (table) [WHERE (conditionals)]
There are two ways to select columns. The first is using * to select all columns, and the second is to specify a list of specific columns you wish to see. The second is quite handy when you want to find a specific column in a rather large list of them. Let's start out with using SELECT with * to specify all columns:
Code Listing 3.10: Viewing the products table
MyDB=> SELECT * FROM products;
product_id | description | price
------------+----------------+-------
1 | A test product | 12.00 2 | meat | 6.79 3 | soup | 0.69 4 | soda | 1.79
(4 rows)
As shown here, all the data we inserted earlier is indeed in the table. Now let's say we only want to see the description and the price, and don't care about the product id. In this case we'll use the column specific SELECT form:
Code Listing 3.11: Viewing specific columns from the products table
MyDB=> SELECT description,price FROM products;
description | price
----------------+-------
A test product | 12.00
meat | 6.79
soup | 0.69
soda | 1.79 606

Gentoo и СУБД
(4 rows)
Now only the product and price is shown, letting us focus on only the important data.
Now let's say that we want to see only the items that are greater than $2.00. Here's where the WHERE clause comes in handy:
Code Listing 3.12: Viewing specific rows from the products table
MyDB=> SELECT description,price FROM products WHERE price > 2.00;
description | price
----------------+-------
A test product | 12.00
meat | 6.79
(2 rows)
Now a listing of products over $2.00 is displayed, focusing the data even more. These forms of querying for information are very powerful, and can help create extremely useful reports.
Conclusion
This concludes the PostgreSQL Guide. A big thanks goes to Masatomo Nakano, the previous Gentoo PostgreSQL maintainer for his help in answering my questions. Any suggestions on this guide should be sent to Chris White. For more extensive documentation, see the
PostgreSQL website
607

Gentoo и системы контроля версий.
Gentoo и системы контроля версий.
Gentoo и Subversion.
HOWTO Subversion сервер при помощи Apache2 и WebDav
Ссылка на оригинал: http://ru.gentoo-wiki.com/HOWTO Subversion сервер при помощи Apache2 и WebDav
C версии: 1.5
О чем эта статья
Данное HOWTO является вольным переводом оригинальной английской статьи.
Также в статью добавленно некоторое количество отсебятины по поводу и без
(надеюсь автор оригинала не знает русского и не увидит как я испохабил его несчастную статью).
Данная статья посвещена настройке сервера Subversion под Apache с
применением WebDav и только ей. Информацию по клиенту и настройке автономного сервера можно найти по ссылке en:HOWTO Subversion
Предупреждение: Данная статья предусматривает, что читатель - разумный человек и не будет вешать репозиторий не на ssl хост, и вообще заботится о безопасности.
FIXME: Хорошо бы описать в чем плюсы WebDav подхода и в чем минусы
Настройка WebDav глобально, безотносительно в virtual-хостам
Apache. Компиляция без Worker MPM
Существует известная проблема при больших коммитах (commit, оффициальный перевод - "фиксация изменений", на мой взгляд длинновато) связанная с использованием апачевого (от Apache) "worker" MPM. Рекомендуется просто отключить этот MPM и скомпилировать Apache с "prefork" MPM. Для этого просто добавьте новую (или поменяйте существующую, если таковая уже есть) строчку в package.use (в случае использования Gentoo, естественно):
Файл: /etc/portage/package.use www-servers/apache -mpm-worker mpm-prefork
После чего перекомпилируйте Апач: emerge -aDNtuv apache
Более того, пожалуйста убедитесь, что subversion скомпилированна с (use flag)
apache2
и без
nowebdav
юзами (от use flags).
Включение SVN и WebDav модулей в Apache
Для использования WebDav и Subversion модулей их, как ни странно, необходимо включить. Делается это при помощи передачи соответсвующих опций (далее - дефайнов, от Define) Апачу при загрузке. Также, для аутентификации, вам возможно понадобится SSL (если вам так не кажется, советую подумать еще раз).
608

Gentoo и системы контроля версий.
Добавте следующую строчку после уже существующей APACHE2_OPTS строчки.
(-D SVN_AUTHZ необходимо для использования авторизации, см. ниже)
Файл: /etc/conf.d/apache2
APACHE2_OPTS="$APACHE2_OPTS -D SVN -D SVN_AUTHZ -D DAV -D SSL"
Создание репозиториев применительно к данной конфигурации
Необходимо, чтобы Апач имел права на запись на папку репозитория(иев), с которым(и) он должен работать. Это можно сделать двумя способами:

Сменой пользователя/группы папки репозитория:
1. Воспользуйтесь командой chown apache:apache
/путь/к/репозиторию/ -R

Добавлением пользователя apache (или того, под которым ваш Апач бегает) в группу svnusers:
1. Для начала надо таковую группу создать: groupadd svnusers
2. Теперь надо добавить пользователя apache в новосозданную группу:
usermod -G svnusers -a apache
3. Ну а теперь надо поменять группу папки репозитория на новосозданную: chgrp svnusers /var/svn/repos/test -R
4. Осталось всего ничего - сделать то, ради чего все это было нужно - дать доступ на запись группе svnusers:
chmod g+w
/var/svn/repos/test -R
Лично я, переводчик, рекомендую воспользоваться комбинацией этих способов, из соображений, что права на запись могут понадобится не только Апачу, а включать страждущего пользователя в группу apache тоже как-то нехорошо, т.к. это даст доступ не только к репозиториям. Для упрощения этой задачи мною был написан следующий скрипт:
Файл: create_repository.sh
#!/bin/sh
DIR_MODE=770
FILE_MODE=660
SVN_ROOT="/var/svn"
SVN_USER="apache"
SVN_GROUP="svn"
NAME=${1:?"Usage: create_repository.sh "}
REPO_DIR="${SVN_ROOT}/${NAME}"
svnadmin create "${REPO_DIR}"
chown "${SVN_USER}:${SVN_GROUP}" -R "${REPO_DIR}"
find "${REPO_DIR}" -type d -exec chmod ${DIR_MODE} {} +
find "${REPO_DIR}" -type f -exec chmod ${FILE_MODE} {} +
# vim: nobackup
609

Gentoo и системы контроля версий.
Базовая настройка
Вместе с subversion устанавливается файл
/etc/apache2/modules.d/47_mod_dav_svn.conf
(в случае включенного юза
apache2
), в котором и содержится практически работающий конфиг (от config - настройка).
Инструкция

DAV svn сообщает Апачу о том, что все запросы, чей путь начинается с /svn необходимо обрабатывать при помощи WebDav модуля (Dav svn директива).

Если вам достаточно только одного репозитория то используйте директиву
SVNPath /путь/к/репозиторию

В противном случе, для многочисленных репозиториев, необходимо использовать следующую директиву:
SVNParentPath /путь/к/папке/с/репозиториями
В этом случае все подпапки папки, указанной в SVNParentPath директиве, будут
рассматриватся как репозитории Subversion (Даже если они таковыми не
являются).
Также существует возможность заставить Апач формировать список репозиториев/содержимого в них, в случае захода с обычного брузера. Для этого существует магическая опция SVNListParentPath (Правда данная опция доступна только с subversion версии 1.3, но для настоящего гентушника это все равно уже антиквариат), которую необходимо установить в on:
SVNListParentPath on
ВАЖНО: При использовании SVNListParentPath может так случится, что вы получите 403 Forbidden, а не список репозиториев (Более подробно данный природный феномен описан здесь
). Как вариант избавления, вы можете добавить в описание блока Location заключительный слэш.

В таком случае, вам наверняка также захочется, чтобы Апач также отлавливал и просто путь /svn . Для этого можно воспользоватся магической опцией
RedirectMatch (добавив ее куда-нибудь вовне блока Location), как показанно в нижеприведенном заклинании.
RedirectMatch ^(/svn)$ $1/
Дабы избежать ппроблем, вроде описанной тут:
Resource cannot be created at the destination...
, будет полезно добавить в конфиг директиву:
SVNAutoVersioning On
610

Gentoo и системы контроля версий.
Аутентификация
Стандартная
На данный момент мы, чисто теоретически, имеем работающий Апач с подключенным Сабвершеном (от Subversion). Однако любая подозрительная личность может сделать с нашим репозиторием что захочет, что естественно не входит в наши планы.
Добавление следующих строчек в
/etc/apache2/modules.d/47_mod_dav_svn.conf включит базовую аутентификацию Апача
Файл: /etc/apache2/modules.d/47_mod_dav_svn.conf
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /var/svn/conf/svnusers
Require valid-user
# Тип встроенной аутентификации "Basic" посылает пароли открытым текстом, что есть небезопасно. Чтобы избежать ситуации кражи пароля необходимо добавить следующую директиву, которая будет требовать подключения с ssl
SSLRequireSSL
Примечание: Как несложно догадатся, для того чтобы можно было требовать ssl, его неплохо было бы включить. Как это сделать было описано выше.
Дополнение: Однако намного более завлекательным вариантом является принудительный редирект на ssl хост, т.к. не вводит среднестатистического пользователя в ступор при виде непонятной ошибки на иноземном языке
Начало общефилософского лирического отступления
Также положительным побочным действием предложенного решения является
то, что если у вас стандартный ssl порт уже занят, то таким образом можно
ликвидировать проблему с запоминанием номера порта, просто заходя на http,
а Апач вас уже перешлет на правильный порт (при условии, что вы ему
скажите это делать, естественно - болезненной самостоятельностью
юниксовые сервера, по счастью, не обладают (хотя периодически и кажется,
что они проявляют признаки очень вредного интеллекта, подкидывая все
новые и новые гадости)))
Конец лирическому отступлению
Файл: /etc/apache2/modules.d/47_mod_dav_svn.conf

[...]
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^/(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]
Возможность: Чтобы ограничить доступ только по ssl, недостаточно директивы
SSLRequireSSL в
47_mod_dav_svn.conf
. Для этого необходимо перенести все директивы из
47_mod_dav_svn.conf в файл с дефолтным (от default - по умолчанию) виртуальным хостом для ssl -
XX_mod_ssl_default-vhost.conf
. Также необходимо так поменять номер этого виртуального хоста так чтобы он грузился
611

Gentoo и системы контроля версий.
после mod_dav (все файлы в папке
/etc/apache2/conf/modules.d загружаются в алфавитном порядке). Впрочем это необходимо только тем у кого настолько древний Апач (или настолько новый, кто знает - постоянно туда-сюда эти хосты путешествуют. По моему мнению, их вообще выкинуть можно), что дефолтный хост лежит все еще в modules.d
- их уже месяцов пять как переместили в vhosts.d
Остальным беспокоится не зачем - vhosts.d загружаются после modules.d
Небольшая оптимизация: Однако вместо того чтобы перемещать директивы из файла
47_mod_dav_svn.conf внутрь виртуального ssl-хоста, можно попросту проинклюдить (от include - включать (в себя)) туда целиком файл, предварительно поменяв ему расширение на что-нибуть отличное от .conf, либо вынеся вовне
{{filename|modules.d}, дабы самостоятельно Апач его не разыскал. Делается это при помощи магической директивы Include с указанием абсолютного пути до желаемого файла
Начало лирического отступления о культурных особенностях индейцев
Вообще-то можно указать и относительный, но стоит учитывать, что Апач -
индеец и имеет несколько свои представления о том что такое
"относительный путь". Для него это путь относительно истинного пути -
путь ServerRoot'а - т.е. по умолчанию откуда-то от
/usr/lib/apache2
Конец лирическому отступлению
Оптимизация побольше и по-глобальнее: По-умолчанию Апач грузит все конфиги в папке {{filename|modules.d} по маске {{filename|modules.d/*.conf}, так что можно немного переписать систему инклюдов, дабы разделить конфиги на обычные и продвинутые-ssl-ные. Для этого достаточно переименовать полюбившийся конфиг, в нашем случае -
47_mod_dav_svn.conf
, в что-нибудь с расширением отличным от .conf (либо, как уже было предложено выше, создав отдельную папку для подобных продвинутых конфигов), к примеру в
47_mod_dav_svn.ssl-conf
. Тогда достаточно будет указать в httpd.conf
(или любом другом глобальном конфиге - к примеру в modules.d/40_mod_ssl.conf
), внутри соответствующего блока / следующие строчки:
# Загрузить модули зависщие от ssl
Include /etc/apache2/modules.d/*.ssl-conf # либо
/etc/apache2/modules.ssl.d/*.conf



Поделитесь с Вашими друзьями:
1   ...   47   48   49   50   51   52   53   54   ...   79


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал