Несколько способов создать загрузочную флешку Windows 7 из под linux.

Способ первый:

Командой fdisk -l определяем флешку. Затем с помощью dd записываем iso образ c windows на флешку:

# dd if=/home/user/windows7.iso of=/dev/sdX

Где /dev/sdX — флешка. Теперь вот здесь качаешь и по инструкции устанавливаешь утилиту ms-sys, которая пропишет правильную MBR для нашей флешки.

Установка простая:

2. Installation

---------------

Step 1, unpack the archive:

tar -xzvf ms-sys*.tgz

Step 2, compile:

cd ms-sys

make

Step 3, become root and install

su (and give password)

make install

Думаю здесь всё понятно. Затем выполняем:

# ms-sys -7 /dev/sdX

Загружаемся с флешки и устанавливаем windows.

Способ второй:

С помощью unetbootin. Сразу скажу, что не знаю насколько работает этот способ. У меня изначально не сложились отношения с unetbootin, на мой взгляд слишком сырая программа, ИМХО. Но многим нравится.

Для начала нужно отформатировать флешку в ntfs. Проверьте чтобы флешка была отмонтирована. Если это не так, то отмонтируйте командой umount. Форматируем:

# mkfs.ntfs /dev/sdX

Затем устанавливаем unetbootin.

# apt-get install unetbootin

Запускаем. Выглядит она вот так:

Выбираем образ, ваш носитель(/dev/sdX) и нажимаем «ОК». После создания флешки, загружаемся с неё и устанавливаем windows.

Способ третий:

На мой взгляд самый лучший и простой способ. С помощью утилиты winusb. Плюс этой утилиты в том что на флешку она ставит загрузчик grub, который отлично загружается практически на всём возможном железе. И уже grub запускает установщик windows. Установка програмы очень проста:

# add-apt-repository ppa:colingille/freshlight

# apt-get update

# apt-get install winusb

А интерфейс ещё проще чем установка.

Выбираете либо iso образ, либо диск в приводе. Выделяете вашу флешку. Затем жмете кнопку install. Загружаетесь с флешки, устанавливаете windows.

Вот три простейших способа создать загрузочную флешку windows 7 из под Linux.

WordPress по умолчанию сохраняет ревизии записей в базе mysql. В большинстве случаев эти ревизии не нужны, но они существенно замедляют работу базы mysql и увеличивают её размер.

В первую очередь отключим сохранение ревизий. Откроем файл wp-config.php в папке сайта. И добавим в него строку:

define('WP_POST_REVISIONS', false);

Перед выполнением работ с базой сделаем дамп базы на случай непредвиденных последствий.

# mysqldump -u пользователь_mysql -p имя_базы_wordpress > dump.sql

Система спросит пароль пользователя mysql.

Мы сделали дамп, теперь можно работать с базой. Если что-то пойдёт не так, мы всегда можем восстановить её из дампа. Подключимся к серверу mysql

# mysql -u пользователь_mysql -p

Система спросит пароль пользователя mysql, логинимся. Всё, мы в консоли mysql.

Выберем базу с которой будем работать, соответственно нам нужно знать название базы с которой работает wordpress.

mysql> USE имя_базы_wordpress;

Удаляем метаданные

mysql> DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type = ‘revision’ AND post_name LIKE ‘%revision%’);

Удаляем таксономию

mysql> DELETE FROM wp_term_relationships WHERE object_id IN (SELECT ID FROM wp_posts WHERE post_type = ‘revision’ AND post_name LIKE ‘%revision%’);

Теперь удаляем сами ревизии.

mysql> DELETE FROM wp_posts WHERE post_type = ‘revision’ AND post_name LIKE ‘%revision%’;

И в конце выполняем оптимизацию таблицы

mysql> OPTIMIZE TABLE wp_posts;

Всё, ревизии удалены. Проверяем работоспособность сайта.

На некоторых виртуальных серверах VPS(VDS) не работает автозапуск mysql после ребута, из-за настроек стартового скрипта mysql. Исправить это довольно просто. Нужно указать mysql, что стартовать нужно независимо от настроек сети и файловых систем. В файле /etc/init/mysql.conf комментируем строки:

#start on (net-device-up
# and local-filesystems
# and runlevel [2345])

И после них дописываем:

start on runlevel [2345]

Vds manager хранит пароли в виде хеша в файле /usr/local/ispmgr/etc/vdsmgr.conf

Для смены пароля на понадобится известный хеш. Возьмем например хеш root пароля из файла /etc/shadow

# cat /etc/shadow|grep root

Копируем строчку с хеш пароля и заменяем старый хеш в vdsmgr.conf. Затем перезапускаем панель

# killall -9 vdsmgr

Заходим в панель с логином admin и паролем root. И меняем пароль на новый.

Делать это будем через маленькую утилиту ssmtp. Допустим что у нас есть почта на собственном домене в яндексе.

Установим ssmtp, для дебианоподобных систем так:

# apt-get install ssmtp

Очищаем конфиг /etc/ssmtp/ssmtp.conf и пишем свой:

mailhub=smtp.yandex.ru #адрес smtp сервера яндекса
AuthUser=post@anikin.pw #ящик с которого будем отправлять
AuthPass=pAssw0rd #пароль к ящику
rewriteDomain=anikin.pw #принудительное указание домена в поле From
hostname=anikin.pw #hostname тачки
FromLineOverride=NO #Запрещает скриптам «решать» с какого ящика отправлять письмо.
Root=admin@anikin.pw #ящик куда будет отправлятся почта предназначеная root

Идем в файл /etc/ssmtp/revaliases и прописывам пользователей и значение, которое будет выставлятся в поле From для каждого из указаных пользователей:

www-data:post@anikin.pw

Пользователей не указаных в этом файле smtp-сервер отфутболит и почта не уйдёт.

Проверяем отправку почты с сайта. После этих настроек почта должна уходить. Данная утилита подойдёт для небольшого количества отправляемух писем, отправка не быстрая. Обычно несколько секунд. Подходит для небольшого проекта. Если у вас большой серьёзный проект, то лучше воспользоваться другими решениями.

P.S. С 16 сентября 2014 года Яндекс.Почта полностью перешла на протокол SSL. При передаче данных по IMAP/POP3/SMTP сервис требует шифрование по SSL, соответственно эта статья потеляла свою актуальность. Правильный конфиг для ssmtp есть в статье Отправка почты с сайта через smtp.yandex.ru на своём домене.(Иcправление)

Недавно обновлял на давно установленном сервере версию PHP с 4.x до 5.4. Версия FreeBSD, если память мне не изменяет, 8.2. При установке libgd получаю ошибку:

tar: Unrecognized archive format

Формат архива порта .xz, путем продолжительного гугления решить проблему не удалось. Порты обновлены, ядро системы пересобрано, но ошибка всё равно возникает. В инете эта ошибка известна, но почему то всё ещё нормального решения её нет. Ну или я его не нашёл. В конце концов я придумал решение самостоятельно, распаковал архив в отдельную папку и уже в ней сконфигурил и скомпилял, данную библиотеку. Возможно решение не лучшее, но это единственное что мне помогло.

Рассмотрим как настроить PPTP сервер в контейнере OpenVZ. В контейнере должны быть включены модули ядра iptables и ppp. Если у вы арендуете сервер, то пишете в техподдержку. Если у вас есть доступ к ноде, то включаете их. На ноде выполняем команды, предварительно стопнув контейнер:

# modprobe ppp_async

# modprobe ppp_deflate

# modprobe ppp_mppe

# vzctl set 001 --features ppp:on --save

# vzctl set 001 --devices c:108:0:rw --save

Где 001 номер контейнера. Запускаем контейнер и внутри него выполняем:

# mknod /dev/ppp c 108 0

# chmod 600 /dev/ppp

Мы включили модуль ppp. Теперь нам надо включить модули натирования. Стопим контейнер снова и на ноде выполняем: # vzctl set 001 --save --iptables "ip_conntrack iptable_filter iptable_mangle ipt_state iptable_nat ip_nat_ftp ip_conntrack_ftp"

Запускаем контейнер. Затем настройка будет происходить в самом контейнере. Установим pptpd # apt-get install pptpd

Приводим файл /etc/ppp/pptpd-options примерно к такому содержанию:

name pptpd #имя сервера
refuse-pap #отключаем аутентификацию pap, chap, mschap
refuse-chap
refuse-mschap
require-mschap-v2 #включаем аутентификацию mschap v2
require-mppe-128 #включаем 128 битное шифрование
ms-dns 8.8.8.8 #DNS-сервер
logfile /var/log/pptpd.log #куда писать логи
nodefaultroute
lock
nobsdcomp

Приводим файл /etc/pptpd.conf примерно к такому виду:

option /etc/ppp/pptpd-options
logwtmp
localip 192.168.0.1 #локальный ip сервера
remoteip 192.168.0.2-254 #ip клиентов
bcrelay venet0:0

Создаём логины и пароли пользователей в файле /etc/ppp/chap-secrets:

# Secrets for authentication using CHAP
# client server secret IP addresses
user pptpd password *

Перезапускаем сервер:

# /etc/init.d/pptpd restart

Теперь пропишем в файле /etc/rc.local команду натирования, чтобы разрешить нашим клиентам доступ в интернет. Перед exit 0 пишем:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o venet0 -j SNAT —to-source внешний ip контейнера

А в /etc/sysctl.conf разрешим ip-форвардинг, раскомментировав строку:

net.ipv4.ip_forward=1

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

P.S. Иногда требуется включить модуль nat на ноде, хотя по умолчанию он обычно включен. Для этого выполняем:

# modprobe iptable_nat