Установка SAMBA на CentOS 6.5 и шаринг директорий

Рассмотрим самый простой вариант установки SAMBA сервера на CentOS 6.5 и расшарим папку в сеть,а так же создадим папку защищенную логином и паролем. Иногда, я бы даже сказал часто нужно быстро завести самбу и расшарить работникам файлы, так как большинство из низ сидит на Winodws то вариант с NFS или WinSCP не подходит, так как они даже не знают что это такое. Конечно в идеале, если вы делает серьезный SAMBA сервер, с разделением на группы, пользователей то это руководство вам не подойдет, но для самых простых случаем всегда удобно иметь под рукой реальную инструкцию.

Установка SAMBA серверва на CentOS 6.5

Начальные данные.
Операционная система: CentOS 6.5
Имя хоста: backup
Адрес хоста: 10.2.50.75

Проверьте нет ли у вас уже установленных пактов в системе:

Или так:

В моем случае есть, в вашем не должно быть. Теперь ставим пакеты:

Добавляем в автозагрузку:

Если у вас работает IPtables:

Создаем папку которую будем расшаривать:

Копируем конфиг файл в сторону:

Туда записываем все что мы хотим расшарить:

Теперь перезапускаем сервис:

Открываем Run:
step_1

И любуемся своей папкой расшаренной в сеть:
Step_2

Если вы надумали создать папку защищенную логином и паролем, и не доступную другим, нам необходимо сделать следующее, создать пользователя и группу, задать им пароль и исправифть конфиг:

Создаем папку и задаем ией права:

Правим конфиг файл:

Перезапустить сервисы:

Выглядить это будет так:
test-samba-sharing

Для тех кто хочет настраивать самбу через графический интерфейс:

Правим конифг:

Рестартуем сервис:

Пример того как это будет выглядеть:
dsadsa

Как видите все просто если знаешь.

get sftp files ftp.bmp.viaamadeus.com

yum install samba-client samba-common cifs-utils

После установки необходимо создать каталог, в который будет производиться монтирование общей папки:

mkdir -p /mnt/win-share

Далее приступаем к монтированию:

mount -t cifs //server/share$ -o username=userName,password=userPassword /mnt/win-share

Имя пользователя можно к примеру “спрятать” в файл:

username=user
password=pass
domain=domain.local

Использовать можно так:

mount -t cifs //server/share$ -o credentials=/dwn/auth.txt /dwn/win-share

где /dwn/auth.txt наш файл авторизации.

3. Монтируем шару. (в виндосе должна быть расшарена, и выставлены соответствуюшии права на пользователя).
# mount.cifs  //10.0.0.1/share$  /mnt/share  -o iocharset=utf8,codepage=cp866,uid=500,gid=500,rw,user=admin%password

где –
//10.0.0.1/share$ – //ip или имя виндовой машины/имя шары
/mnt/share   –  точка монтирования в Линуксе
iocharset=utf8,codepage=cp866  –  кодировка, дабы и там и там были русские символы, вместо кракозябр.
uid=500,gid=500,rw  –  какой uid и gid будет присвоен нашей подмонтированной шаре, разрешаем чтение/запись.
user=admin%password  –  имя виндового пользователя и его пароль

Второй метод. Теперь,  дабы наша виндовая шара даже после перезагрузки сервера была подмонтирована, добавим запись в fstab.

1. Редактируем fstab
# vi  /etc/fstab

Добавляем в конце всех записей строчку:
//10.0.0.1/share$    /mnt/share  cifs  iocharset=utf8,codepage=cp866,uid=500,gid=500,rw,user=admin%password        0 0
Сохраняем файл и выходим из редактора. Теперь можно не беспокоиться что наша шара не подцепится после перезагрузки.

Третий метод. Теперь сохраним имя пользователя и пароль в отдельном файле, а не в виде записи в fstab.

1. Открываем  fstab
# vi  /etc/fstab
Добавляем в конце всех записей строчку:
//10.0.0.1/share$    /mnt/share  cifs  iocharset=utf8,codepage=cp866,uid=500,gid=500,rw,credentials=/root/pass.txt          0      0

2. Создадим и отредактируем файл который будет содержать имя и пароль виндового юзера (pass.txt)
# vi  /root/pass.txt
Добавим в этот файл следующии строки:
username=admin
password=password

3. Выставим права на этот файл
# chmod  600  /root/pass.txt

 

yum install openssh expect putty

Generate the .pem file from .ppk file with the following command.
puttygen ppkkey.ppk -O private-openssh -o pemkey.pem

vi .conf

vi expect.sh

chmod +x ./expect.sh

 

Secure-preferences

his is Android Shared preference wrapper that encrypts the values of Shared Preferences using AES 128, CBC, and PKCS5 padding with integrity checking in the form of a SHA 256 hash. Each key is stored as a one way SHA 256 hash. Both keys and values are base64 encoded before storing into prefs xml file. By default the generated key is stored in the backing preferences file and so can be read and extracted by root user. Recommend use the user password generated option as added in v0.1.0.

The sample app is available on playstore

Sample app Screenshot
Release v0.1.0+

The v0.1.0 release was a major refactor of the guts of secure prefs, which is Not backwards compatible yet with older 0.0.1 – 0.0.4 versions. So if you have an existing app using this don’t upgrade. I’ll be looking to add migration into a later release.

Full list of changes
Usage
Dependency

Maven central is the preferred way:

Note: v0.1.0 was dependent on snapshot of aes-crypto, this is only as I was waiting for the aes-crypto repo owner to upload to maven. I’ve sorted this for v0.1.1+ which is no longer dependant on Snapshot repo.

Download

Or download the release .aar or clone this repo and add the library as a Android library project/module.
ProGuard config

As of v0.1.4 no specific -keep config is needed.

v0.1.3 There was a bug in 0.0.3 of :aes-crypto which broke secure-prefs when used with proguard

If you are using version v0.1.0 – v0.1.2 please use the below (thanks to @cermakcz):

-keep class com.tozny.crypto.android.AesCbcWithIntegrity$PrngFixes$* { *; }
DexGuard

There is specific DexGuard config supplied with DexGuard 7+ located /samples/advanced/SecurePreferences
Examples

This will use the default shared pref file

SharedPreferences prefs = new SecurePreferences(context);

Custom pref file

You can define a separate file for encrypted preferences.

SharedPreferences prefs = new SecurePreferences(context, null, “my_custom_prefs.xml”);

User password – (recommended)

Using a password that the user types in that isn’t stored elsewhere in the app passed to the SecurePreferences constructor means the key is generated at runtime and not stored in the backing pref file.

SharedPreferences prefs = new SecurePreferences(context, “userpassword”, “my_user_prefs.xml”);

Changing Password

SecurePreferences securePrefs = new SecurePreferences(context, “userpassword”, “my_user_prefs.xml”);
securePrefs.handlePasswordChange(“newPassword”, context);

What does the data look like?

SharedPreferences keys and values are stored as simple map in an XML file. You could also use a rooted device and an app like cheatdroid
XML using Standard Android SharedPreferences

 

XML with SecurePreferences

pD2UhS2K2MNjWm8KzpFrag==:MWm7NgaEhvaxAvA9wASUl0HUHCVBWkn3c2T1WoSAE/g=rroijgeWEGRDFSS/hg

k73tlfVNYsPshll19ztma7U”>
pD2UhS2K2MNjWm8KzpFrag==:MWm7NgaEhvaxAvA9wASUl0HUHCVBWkn3c2T1WoSAE/g=:jWm8KzUl0HUHCVBWkn3c2T1WoSAE/g=

 

Disclaimer

By default it’s not bullet proof security (in fact it’s more like obfuscation of the preferences) but it’s a quick win for incrementally making your android app more secure. For instance it’ll stop users on rooted devices easily modifying your app’s shared prefs. Recommend using the user password based prefs as introduced in v0.1.0.
Contributing

Please do send me pull requests, but also bugs, issues and enhancement requests are welcome please add an issue.
Licence

Much of the original code is from Daniel Abraham article on codeproject. This project was created and shared on Github with his permission.

Apache License, Version 2.0

Copyright (C) 2013, Daniel Abraham, Scott Alexander-Bown

Licensed under the Apache License, Version 2.0 (the “License”);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

The sample app Lock icon for sample app licenced under Creative Commons created by Sam Smith via thenounproject.com

 

AESCrypt-Android

AESCrypt-Android

Install

Download from Maven Central (.aar)

or

Examples

Encrypt

Decrypt

Advanced usage

It’s possible to provide your own key, IV.

To be honest it’s a strech to call this a library given it’s only a single util class, but I created as went through a ton of pain working out the conpatible settings for AESCrypt. I hope this will save some one time in the future.
Contributing

package com.scottyab.aescrypt.java

 

Android Arsenal

Simple API to perform AES encryption on Android with no dependancies. This is the Android counterpart to the AESCrypt library Ruby and AESCrypt-ObjC created by Gurpartap Singh.

For compatiblity with AESCrypt, AESCrypt-Android has the same defaults namely:

256-bit AES key
CBC mode
PKCS7Padding
Blank/Empty IV (default*)

A blank IV is not the best security but the aim here is compatibility with AESCrypt implementations. See Adv method for providing your own IV. If you don’t need to be compatable with AESCrypt then look at java-aes-crypto it’s API is just as simple and generates more secure keys.
Dependency

I welcome pull requests, issues and feedback.

Fork it
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am ‘Added some feature’)
Push to the branch (git push origin my-new-feature)
Create new Pull Request

Licence

Copyright (c) 2014 Scott Alexander-Bown

Licensed under the Apache License, Version 2.0 (the “License”);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

 

MongoDB

Можете немного поэкспериментировать с MongoDB, поработав с ней через оболочку mongo:

$ mongo MongoShortener
MongoDB shell version: 2.0.6
connecting to: MongoShortener

Смотрим список коллекций в базе:

> show collections

Создать новый документ (попробуйте создать два документа с одинаковым code):

> db.urls.insert({ code: 123, url: “http://eax.me/” });

Просмотреть список документов (в поле _id всегда хранится уникальный ID документа):

> db.urls.find();

Создание индекса:

> db.urls.ensureIndex({ code: 1 }, { unique: true });

Просмотр списка индексов:

> db.urls.getIndexes();

Удаление индекса (перезапустите сокращалку и посмотрите, создастся ли он снова):

> db.urls.dropIndex({ code: 1 });

Обновление документа:

> db.urls.update({ code: 123 }, { url: “http://example.ru/” });

Удаление документа:

> db.urls.remove({ code: 123 });

Выход из оболочки:

> exit

Настройка bonding на CentOS 6

Эта статья посвящена вопросу настройки объединения сетевых интерфейсов Link Aggregation (LAG) и использованию протокола LACP (Link Aggregation Control Protocol). Казалось бы все просто – взял сделал бондинг по мануалу и сразу на серваке увеличилась пропускная способность и появилась отказоустойчивость. Отказоустойчивость и правда появится, на тестовое выдергивание одного из сетевых проводов сервер отреагирует вполне лояльно, но менее явная неисправность интерфейса вряд ли будет определена правильно. Пропускная способность объединенного интерфейса очень сильно зависит от того как и в каких направлениях бегает по сети трафик, бывает люди для увеличения скорости между сервером 1с предприятия и терминальным в каждый из них покупают 4-х портовые сетевые карты и настраивают на них 802.3ad, а итоге на тестах получается что скорость между серверами достигает максимум 900Мбит/с.

1. Чуть-чуть теории

Link Aggregation (LAG) – это объединение нескольких физических каналов в один логический с целью объединить пропускную способность и повысить отказоустойчивость.

Объединение пропускной способности происходит при помощи алгоритма балансировки, при этом алгоритм балансировки выбирается на отправляющей стороне. Простой пример – сервер и коммутатор между ними настроен LAG,  все исходящие пакеты сервер сам балансирует и сам распределяет их по интерфейсам, а вот все входящие на сервер пакеты балансируются уже коммутатором. Те алгоритм балансировки должен быть настроен на обоих сторонах, в противном случае трафик будет бежать через одни интерфейс – простая истина, но много граблей на этом сломано.

Большинство алгоритмов балансировки распределяют пакеты по интерфейсам на основе хеш-суммы MAC адресов, IP-адресов, портов назначения и отравителя в TCP/UDP-пакетах, базовые алгоритмы зашитые в большинстве коммутаторов работаю только с MAC или IP+MAC, при этом получается следующая ситуация – все пакеты отправленные с одного сервера на другой могут занять максимум один интерфейс, полную утилизацию 2-х интерфейсов мы сможем получить только если к серверу обратиться два разных клиента с разными MAC адресами и не меньшей скоростью интерфейсов. Исключением является алгоритм balance-rr (round robin) – он умеет разбрасывать трафик между несколькими интерфейсами, но ему нужна поддержка транков или EtherChannel со стороны коммутатора.

Link Aggregation (LAG) может быть статическим или динамическим, главное отличие между ними в том что статика не умеет определять «неявную»  неисправность одного из интерфейсов, поэтому все стремяться сделать динамический LAG. Один из протоколов для динамического объединения каналов  LACP (Link Aggregation Control Protocol) описанный в стандарте IEEE 802.3ad. При использовании LACP обе стороны обмениваются между собой пакетами LACPDU и на основании этих пакетов участники определяют принадлежат ли порты к одному логическому каналу и проверяют состояние физических интерфейсов. При этом стоит заметить что LACP не передает никакой информации об алгоритмах балансировки, они все также выбираются на оборудовании. Как говорят доки, LACP требует минимальной настройки оборудования, вроде как просто указать что он включен, на самом деле на не сильно дорогих железках вроде Cisco SG 200-50, 3com 2924-SPF или HP V1910-48G протокол LACP настраивается для каждой группы портов точно также как и статика.

2. Настройка

Предположим у нас в сервере есть два интерфейса eth0 и eth1, эти интерфейсы мы будем объединять в bond0 и настраивать на них LACP.
Открываем для редактирования /etc/sysconfig/network-scripts/ifcfg-eth0 и приводим его к следующему виду.

По сути мы добавляем в него MASTER=bond0, SLAVE=yes и удаляем все что связано с настройками IP. Тоже самое проделаем с /etc/sysconfig/network-scripts/ifcfg-eth1

Создаем файл с настройками объединенного сетевого интерфейса /etc/sysconfig/network-scripts/ifcfg-bond0.

Расскажу немножко про BONDING_OPTS, часто и очень часто натыкаюсь на то что люди пытаются прописывать в /etc/modprobe.conf загрузку модуля bonding и кучу параметров к нему, не делайте так – это все пережитки прошлого. Было когда-то время и это был единственный способ подцепить бондинг, но в CentOS 5 и 6 директива BONDING_OPTS работает без как часы, при этом менять параметры бондинга можно просто перезапуском сервиса network.
Основной параметр BINDING_OPTS это параметр mode – он определяет в каком режиме будет работать объединенный интерфейс, в нашем случает это 802.3ad – используем LACP протокол. Дальше параметр miimon – отвечает за хардварный мониторинг линка на случай скажем выдергивания сетевого провода, устанавливает в миллисекундах частоту проверки, а по-умолчанию отключен. Говорят что параметр miimon работает не на всех сетевых карточках, проверить его можно через ethtool.

Параметр xmit_hash_policy определят алгоритм по которому Linux будет распределять трафик по сетевым интерфейсам, бывает три варианта: layer2 – по MAC, layer2+3 – по MAC и IP; layer3+4 – по IP и порту. Алгоритм layer2+3 полезен для случая когда между сервером и клиентами установлен роутер, если роутера нет, то вполне можно использовать layer2.
Готово, перезапускаем сервис network.

3. Проверяем

Посмотреть состояние объединенного интерфейса можно в /proc/net/bonding

В результате мы видим те параметры которые забили в BINDING_OPTS, потом 802.3ad info и состояние двух интерфейсов. Важно обратить внимание на 802.3ad info если “Partner Mac Address” равен 00:00:00:00:00:00 – это значит что обмен пакетами LACPDU не произошел и на коммутаторе скорее всего не настроен или не поддерживается LACP.

4. Тестируем скорость

Завершающим аккордом думаю стоит протестировать получилось ли у нас объединение по скорости двух интерфейсов, ибо случаи бывают разные, бывает коммутатор трафик только на один интерфейс гонит, а бывает и мы в настройках чего-нибудь не докрутили. Для тестирования нам понадобится непосредственно наш сервер bksrv (IP: 192.168.10.40) и любые два компьютера-сервера подключенные к тому-же коммутатору, для примера назовем их node1 (IP: 192.168.10.51) и node2 (IP: 192.168.10.52).
Ставим на всех участниках (bksrv, node1 и node2) две утилиты iperf для тестирования скорости и ifstat для отображения загруженности по интерфейсам.
Начнем с входящей скорости, запускаем на проверяемом сервере bksrv утилиту iperf, а затем с другой консоли ifstat

Теперь запускаем iperf с двух клиентов node1 и node2:

Смотрим на ifstat и если скорость на обоих интерфейсах равна приближенно 100MB/s – значит все ок, иначе начинаем разбираться по какому алгоритму коммутатор раскидывает трафик и вообще делает ли он это. Для большей правдоподобности иногда стоит подключится большим количеством клиентов, к примеру вместо двух клиентов node1 и node2, запустить iperf сразу с штук пяти.

Теперь тестируем исходящую скорость, технология та же самая, на клиентах node1 и node2 запускаем iperf в режиме сервера.

И с разных консолей сервера bksrv запускаем iperf в режиме клиента.

Смотрим через iperf исходящую скорость на обоих интерфейсах, и если что не так крутим драйвера интерфейсов и настройки алгоритма балансировки на сервере.

5. Заключение

Вроде бы простую настройку, которую многие проделывают не задумываясь на каждом новом сервере, удалось таки растянуть в достаточно длинную статью. Надеюсь что эта статья была для вас полезной и вы подчеркнули из нее что-то интересное и нужное. Если хочется лучше разобраться в настройке бондинга, то очень неплохое описание есть в доках к ядру.

Желаю успехов. Есть дополнения – пишите.

Установка PPTP-сервера на CentOS

1. Установка PPTP

Устанавливаем PPTP-сервер:

2. Настройка PPTP-сервера

Разрешаем форвард пакетов, в файле /etc/sysctl.conf меняем значение net.ipv4.ip_forward с 0 на 1. Обновляем параметры командой

Загружаем необходимые для работы протокола PPTP через NAT модули. Чтобы модули подгружались при загрузке системы эти команды необходимо добавить в файл /etc/rc.d/rc.local.

Добавляем в файл /etc/pptpd.conf, адрес шлюза и список адресов выдаваемых клиентским компьютера.

Переходим к конфигурационному файлу /etc/ppp/options.pptpd

Добавляем пользователей. Для PAP-аутентификации используется файл /etc/ppp/pap-secrets, для CHAP/MSCHAP – /etc/ppp/chap-secrets. Оба файла имеют по сути одинаковую структуру.

Включаем в автозагрузку и запускаем сервис pptpd

3. Настройка IPTABLES

Для каждого конкретного случая настройка iptables может быть очень специфичной, здесь я опишу настройку некоторого базового варианта: интерфейс eth0 – смотрит в инет, интерфейс eth1 – локальная сеть; политики по умолчанию INPUT DROP (входящий трафик запрещен) , FORWARD DROP (форвардинг пакетов запрещен), OUTPUT ACCEPT (исходящий трафик разрешен).

Разрешаем  входящие подключения на TCP порт 1723 и по протоколу GRE через внешний интерфейс eth0.

При создании каждого подключения pptp создается виртуальный интерфейс ppp, этому интерфейсу присваивается внутренний адрес VPN-клиента. Когда клиент одни все просто – пара разрешающих правил и все готово, но когда клиентов становится больше остаются два варианта: либо смягчить правила разрешив доступ со всех интерфейсов ppp и всего пула remoteip в локальную сеть и обратно, либо создавать и удалять правила динамически. Второй вариант на мой взгляд явно лучше.

Создаем файл скрипта для открытия подключения /etc/ppp/ip-up.local, этот скрипт будет запускаться автоматически после создания интерфейса ppp при подключении клиента.

Создаем файл скрипта для закрытия подключения /etc/ppp/ip-down.local, этот скрипт будет автоматически запускаться перед удалением интерфейса ppp при отключении клиента.

Единственное жалко, что скрипту не передается в параметрах имя пользователя – можно было более детально разграничить доступ к ресурсам: одним – одни ресурсы, другим – другие.

4. Заключение.

PPTP достаточно прост в установке и настройке. Одно из преимуществ – не требует от конечного пользователя каких либо серьезных навыков и знаний в области компьютерных технологий для настройки подключения, которое легко организуется за счет штатных средств современных ОС.

Главные недостатки заставляющие смотреть с торону других протоколов – низкая защищенность передаваемых данных и слабая устойчивость к атакам.

Работа с объемом диска в LINUX команды df и du

Начну сразу с двух особенностей:

UFS: Почему возможно заполнение раздела больше чем на 100%?
Часть каждого раздела UFS (по умолчанию 8%) зарезервировано для использования операционной системой и пользователем root. Утилита df(1) не учитывает это при подсчёте значения в колонке Capacity, так что оно может превышать 100%. Также вы заметите, что колонка Blocks всегда больше, чем сумма значений в колонках Used и Avail, обычно на 8%.

ext 2/ext3 5% файловой системы резервируется под рута.

Зачем это делается:

«А это на тот случай, если у тебя какой-нибудь мудак повесит в фоне cat /dev/random > myfile и уйдет домой спать. Файлуха переполнится и с некоторой долей вероятности нельзя будет даже прилогиниться – зависит от того, как у тебя разбиты точки монтирования.
А так – 5% файлухи (задаётся ключом -m в соответствующем mkfs) резервируется под рута, всем остальным будет возвращаться ошибка. Так что как минимум прилогиниться и почистить систему тебе хватит.»

Исходя из этого вот такая картина почти нормальная:

df -h

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/VolGroup00-LogVol00

444G 56G 365G 14% /

/dev/sdb1 99M 13M 82M 14% /boot

tmpfs 3.0G 0 3.0G 0% /dev/shm

/dev/sda5 917G 908G 0 100% /mnt/data

Обращам внимание на /dev/sda5 .

Полезные команды:

root@server [~]# df -ah
Filesystem Size Used Avail Use% Mounted on
/dev/vzfs 20G 5.0G 1017M 84% /
proc 0 0 0 – /proc
sysfs 0 0 0 – /sys
none 7.9G 4.0K 7.9G 1% /dev
none 0 0 0 – /dev/pts
none 0 0 0 – /proc/sys/fs/binfmt_misc

Если мы хотели бы просмотреть информацию об использовании inode (максимальное число теоретически возможных файлов на данной файловой системе), то это можно проделать с помощью опции -i.
root@server [~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vzfs 20971520 176654 20794866 1% /

если нет надобности выводить информацию по какой то из файловых систем, то её можно исключить используя опцию -x , а опцией -t можно ограничить вывод определенными типами файловых систем.
root@server [~]# df -ah -x sysfs
Filesystem Size Used Avail Use% Mounted on
/dev/vzfs 20G 5.0G 893M 85% /
proc 0 0 0 – /proc
none 7.9G 4.0K 7.9G 1% /dev
none 0 0 0 – /dev/pts
none 0 0 0 – /proc/sys/fs/binfmt_misc

В моем примере видно, что творится какая то чертовщина, поскольку разница общего и использованного объема составляет 15 Гигов, при том, что свободным у меня остается 1Гиг. Явно что какой то глюк, поэтому надо смотреть кто и сколько кушает. Для этого мы воспользуемся утилитой du (сокращение от disk usage), предоставляющей нам информацию об использовании диска файлами и директориями.
root@server [~]# du -hsx /
5.4G /

Это общий размер дискового пространства занимаемого файловой системой / . Чтобы посмотреть разблюдовку по директориям в корневой файловой системе:
root@server [~]# du -shc /*
0 /aquota.group
0 /aquota.user
5.0M /bin
4.0K /boot
4.0K /dev
6.5M /etc
887M /home
24M /lib
4.0K /media
4.0K /mnt
14M /opt
0 /proc
4.8M /root
21M /sbin
7.8M /scripts
4.0K /selinux
4.0K /srv
0 /sys
12K /tmp
4.2G /usr
354M /var
1.5M /yum
1.4M /yum-ce5.tar.gz
5.4G total

Где опция -s выводит итоговый объям для кадого аргумента, опция -h пишет нам в удобочитаемом формате, опция -c заканчивает список общей суммой.
Естественно, что проделывать все операции необходимо из под пользователя имеющего права чтения на директории.

При одновременном использовании этих команд, в большистве случаев мы получим разные результаты вывода для каждой из них. Это вызвано различными алгоритмами работы данных утилит, которые следуют из их названий: утилита df считает общий суммарный объем блоков, помеченных в суперблоке файловых систем как свободные, в то время как утилита du исходит из информации об объеме занятом файлами, отправляясь от описания в метаданных.
В связи с тем, что операции файловой системы абсолютно во всех случаях, так или иначе, кэшируются, то довольно часто может возникнуть ситуация, когда файл физически удален, т.е. имя файла удалено из записи каталога, а в карте занятости, освобождение соответствующего пространства еще не произошло, и тогда, как раз, блоки данных будут подсчитываться при использовании df, и будут не учтены в результатах du.

Еще можно посмотреть сколько место занято по дерикториям du -hd 1
(ключик d задает вложенность показа).

Защищаем сервер. IPtables ограничить соединения по IP

Если вы хотите защитить ваш сервер от флуда или перебора паролей, можно в первую очередь ограничить количество соединений с одного IP адреса. Сделать это можно с помощью iptables.
Например:
/sbin/iptables -A INPUT -p tcp –syn –dport $port -m connlimit –connlimit-above N -j REJECT –reject-with tcp-reset
Вот пример для соединений по SSH:
/sbin/iptables  -A INPUT -p tcp –syn –dport 22 -m connlimit –connlimit-above 3 -j REJECT
Так же пример для HTTP:
/sbin/iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-above 20 -j REJECT –reject-with tcp-reset
Так же можно лимитрировать на какое то время, например с помощью скрипта:
#!/bin/bash
IPT=/sbin/iptables
# Max connection in seconds
SECONDS=100
# Max connections per IP
BLOCKCOUNT=10
# ….
# ..
# default action can be DROP or REJECT
DACTION=”DROP”
$IPT -A INPUT -p tcp –dport 80 -i eth0 -m state –state NEW -m recent –set
$IPT -A INPUT -p tcp –dport 80 -i eth0 -m state –state NEW -m recent –update –seconds ${SECONDS} –hitcount ${BLOCKCOUNT} -j ${DACTION}
# ….
# ..