shurph

Создайте на своём сайте отдельную страницу, где перечислите все имена всех авторов, а ссылку на эту страницу оставьте в футере в виде текста копирайта.

Если вы запускаете скрипт через cron, то он выполняется в cli режиме. А в cli режиме у php нет лимитов на время выполнения скрипта.

Если же ваш скрипт при запуске из крона падает, то, скорее всего, он превышается какие-то другие лимиты (скорее всего, потребляет больше памяти, чем разрешено).

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

UPD: но вы, всё же, можете сделать поэтапное выполнение скрипта: сгенерировать дополнительным скриптом подзадачи, положить эти задачи в какую-нибудь БД, а потом запускать ваш основной скрипт несколько раз, а он уже будет брать задачи из такой вот кустарной очереди. Ну или можно использовать какие-нибудь готовые менеджеры очередей :)

Есть компилятор py2exe, только к нему ещё нужно будет найти в интернете пару-тройку dll'ек от вижуал студии, на сколько я помню.

upd:, а, или имеется ввиду собрать exe'шник под линуксом для винды, не имея винды? Лучше не заморачиваться. Скачайте виртуалку с сайта микрософта.

Конфиг должен выглядеть как-то вот так (только нужно ещё подшаманить регулярные выражения, чтобы нормально обрабатывались случаи отсутствия get параметров в оригинальном запросе (я оставил комментарии в этом месте конфига)):

server {
	listen 80;
	server_name dom1.com;
	
	root /vhosts/dom/www;
	index index.html index.htm index.php;
	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass unix:/var/run/php5-fpm-dom.sock;
		fastcgi_index index.php;
		root /vhosts/dom/www;
		include fastcgi_params;
	}
	location / {
		try_files $uri $uri/ /$uri /index.php?q=$uri$args /mailer.php?q=$uri$args /hecher.php?q=$uri$args;
	}
}
server {
	listen 80;
	server_name www.dom1.com;
	location / {
		rewrite ^/(.*)$ dom1.com/$1 permanent;
	}
}
server {
	listen 80;
	server_name www.dom2.com
		dom2.com;
	location / {
		# будет работать, если во всех урлах передаётся какой-то get параметр
		# т.е. оригинальная ссылка толжна быть dom2.com/?smthng=blabla, чтобы
		# получить dom1.com/?smthng=blabla&utm_source=dom2.com&utm_medium=redirect
		# иначе может получится нерабочая ссылка вида dom1.com/page/&utm_source=dom2.com&utm_medium=redirect
		rewrite ^/(.*)$ dom1.com/$1&utm_source=dom2.com&utm_medium=redirect permanent;
	}
}

Нужно делать именно так, как вы написали в "P.S.", только для уменьшения простоя делать это на копии проекта, а потом подменить каталог оригинала проекта на каталог копии.

Вообще, не очень понятно ваше беспокойство о простое. У вас нет процесса деплоя? Разрабатываете прямо на продакшене? Это очень пагубная практика.

И деплой кода средствами git'а мне кажется тоже пагубной практикой, если у вас это сделано так.

Похоже, что проксировать все порты автоматически не получится. Для каждого порта нужно будет прописывать в конфиге строчки отдельно. Для вашего примера понадобится что-то такое:

server {
    listen 22;
    server_name example1.com;
    location / {
        proxy_pass http://192.168.1.1:22;
    }
}
server {
    listen 22;
    server_name example2.com;
    location / {
        proxy_pass http://192.168.1.2:22;
    }
}

про remote_addr почитайте вот это:
habrahabr.ru/post/177113
На сколько я понимаю, поместить в remote_addr адрес пользователя не получится на стороне nginx'а.

UPD (на основе дискуссии в комментариях):
у меня есть сомнения, что такое возможно настроить с помощью nginx (да и вообще — настроить).
Во первых, nginx — это http сервер и, соответственно, http прокси (разве что ещё почтовые протоколы он поддерживает). Если нужны другие протоколы, то и использовать стоит другие решения.

Во вторых, я очень не уверен, что при подключении по другим протоколам вы сможете определить, что пользователь подключается к домену example1.com, а не к example2.com.
Ведь как определяется домен в случае http? Браузер передаёт такой запрос на сервер, подключаясь к example1.com:

GET / HTTP/1.0
Host: example1.com

По первому вопросу: разве в 2014 году является проблемой выделить для рабочего инструмента 2 гигабайта?

По второму: старайтесь выключать виртуалку через vagrant halt. Похоже, после неудачного выключения виртуалка у вас зависает на экране grub'а.

3: Наверное, это можно сделать вот так:

config.vm.synced_folder "./", "/vagrant", disabled: true

но я не понимаю - зачем?

4: попробуйте воспользоваться опцией:
xdebug.remote_host = 10.0.2.2

Поэтому я использую обычный текстовый файл в формате markdown, который лежит под системой контроля версий (git в моём случае). Каждый год я создаю новый файл.

Выглядит это так:
Файл разбит на две части: «К прочтению» и «Прочитано». Одна книга — одна строчка в файле.
После прочтения книги я переношу соответствующую строчку в раздел «Прочитано» и под ней пишу свои мысли о книге. После чего коммичу изменения в репозиторий (в коммит можно также добавить какой-то комментарий о книге).

В результате чего у меня есть список книг к прочтению, список прочитанных книг с небольшими комментариями к ним, а также информация о том, когда каждая из книг была прочитана (и, соответственно, динамика моего чтения).

Т.к. используется гит, то я могу безболезненно хранить «бекап» всего этого на каком-нибудь битбакете и, соответственно, в любое время и в любом месте иметь доступ к этим данным.

Как вы собираетесь с markdown решать такие задачи, как расположение изображений на странице; сносок; написание формул; правильная нумерация формул, изображений, вставок кода; подсчёт этих формул, изображений, вставок кода; оформление титульного листа; работа с библиографией; соответствие оформления ГОСТам и другим стандартам, в конце концов?

Фактически, выбирая markdown, вы нагружаете себя дополнительной работой по решению всех вышеперечисленных проблем, в то время как большая их часть уже давно решена теми, кто использует LaTeX.

В конце концов, если в вашем дипломе предполагается очень простое форматирование, то можно попробовать писать основной текст в markdown, а потом конвертировать его в LaTeX, но грабли всё равно будут.

Так что, лучше потратить 2-3 вечера на знакомство с полезным инструментом :)