alexandrnevajno1, Я не очень понял ваш вопрос. Вы столкнулись с тем, что поведение одного и того же скрипта разное от системы к системе. И это различие зависит не от скрипта, а от того, как операционная система понимает имена файлов. Для windows filename и Filename один и тот же файл, для linux разные.
Вы можете у себя в скрипте проверять имена файлов как любые другие строки на соответствие какому-то регулярному выражению, или любому другому условию, но поведение операционной системы это не изменит - только поведение конкретного скрипта...
Да, тут вы совершенно правы, я не внимательно прочитал вопрос. Обычно такая пролема всё же не при просмотре структуры, а при работе с дампам...
Но всё же, и в этом случае, крайне советую не пользоваться разными админерами с сипекс дамперами и прочими костылями, и не плодить себе лишние дыры, а использовать нормальные клиенты через нормальные защищённые каналы, и не запускаемые в сильно ограниченной по времени выполнения/размеру загружаемого и.т.п. среде...
Кажется я понял, в чём у вас проблема.
Уточню: начинают работать сатйты, которые находятся на том же бекэнде, что и указанный в конфиге?
Вам нужен конфиг под каждый сайт, и конфиг под сайт по умолчанию, который будет ловить запросы, которые не относятся к остальным доменам, и возвращать ошибку или заглушку. То же нужно и для http, кстати.
Опишите максимально подробно, что именно происходит... Что значит открываются все? Что значит не работает? Не работает по http? По https? Если второе, то не удивительно. Если первое, какая ошибка?
Как узнать на каком ip и порту висит конкретный сайт?
Из конфигурации веб сервера который обеспечивает его работу, вероятно.
Если в /etc/nginx/include/ssl сертификаты для нужного сайта, а sitename.net на этой машине резольвится в нужный ip адрес того бекэнда, который должен обрабатывать запросы, то всё верно. Но скорее всего там должно быть прописано http://ip:port бекэнда. И проблема именно в proxy_pass http://sitename.net;
Все запросы почему-то так и идут на IIS...
Можно подробнее об этом? Мимо nginx идут? Или после nginx идут не туда? Или в чём вообще проблема?
А зачем вам на каждое новое соединение создавать новый процесс. Процесс создаётся один раз, затем, когда приходит запрос от клиента, ему передаются данные, и он возвращает ответ. Если запросов много, и один экземпляр демона становится узким местом, создаются несколько экземпляров, и возможно, используется балансировщик перед ними.
Подключиться можно хоть через сокет, хоть через очередь сообщений, хоть через свой велосипед в базе или key-value. Как напишите, так и будет.
С pid процесса внутри, и проверять не только наличие файла, но и наличие процесса с таким pid, а если процесса нет, удалять файл и запускать инстанс процесса.
Процессы, бывает, падают, и если просто файл как блокировка будет использоваться, всё встанет.
Нет. Это же пример просто.
Вам, на самом деле, надо в fastcgi_pass написать адрес/порт, или путь до сокета, на котором у вас висит php-fpm.
upstream вам не нужен - он применяется тогда, когда надо обеспечить обработку на нескольких серверах, прежде всего...
Для того, чтобы знать, что именно написать, надо посмотреть в конфиг пула php-fpm, который должен обрабатывать запросы.
А вообще, судя по всему, вам надо серьёзно разобраться в том, что вы делаете, или лучше обратиться к тому, кто в этом разбирается.
Что же, у меня ровно обратный опыт в проведении аналитики на основе картинки: даже переходов по ссылке в письме было больше, чем показов встроенных картинок. Соответственно, письмо не только видели, но даже и взаимодействовали с его содержимым куда больше людей, чем было обращений за картинками.
Можно экстраполировать данные - "столько-то процентов открыло" на основе картинки и статистики, но дать настоящую количественную оценку на основе этого метода нельзя. Она будет заведомо занижена.
Александр Аксентьев, Имено наоборот. БОльшее количество почтовиков не открывает внешние картинки, без действия пользователя, или изменения настроек.
А сервисы рассылок в рекламных материалах просто очень преувеличивают свои возможности отслеживания открытия писем, даже не смотря на то, что используют не только картинки.