Артем Кайбагоров

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

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

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

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

Ну и когда все готово, отвязываем пациента, даем выпить стакан водки, и выставляем счет.

Собственно вопросы заключаются в том, рабочая ли схема, какие могут быть нюансы или трудности (я не хирург) или как удобней организовать тот или иной пункт?

После развертывания LTSP в песочнице было решено оставаться на Windows. С учетом необходимости обучения персонала, Windows становится дешевле.
Всем спасибо.

Когда возникла необходимость появления на рынке 64 разрядных CPU мнения Intel и AMD по этому поводу кардинально разделились. Intel предложили технологию IA64 которая ни как не стыкуется со старой 32 разрядной х86 (которой 40 лет, однако). AMD вышли на рынок с технологией AMD64 которая в ущерб производительности сохранила совместимость с х86 что позволило на новых процессорах напрямую выполнять старый код. Ожидаемо, что замечательная идея от Intel не имела коммерческого успеха и весь ширпотреб Intel выпускает по стандарту AMD64, который адепты Intel стыдливо именуют х64 или х86-64

Зря тут речь идет про Windows 7. Под такое дело хорошо работает Debian, проверено.
Более того, буквально парой строчек в конфиге можно ограничить браузер одним сайтом.
А в винде дыры так или иначе все равно найдутся...

Конфиг киоска на Debian:
/etc/rc.local :

!/bin/sh -e
iptables -t filter -A INPUT -p tcp -s YOUR_SITE.ru --dport http -j ACCEPT
iptables -t filter -A OUTPUT -p tcp -d YOUR_SITE.ru --dport http -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport http -j DROP
iptables -t filter -A OUTPUT -p tcp --dport http -j DROP
iptables -t filter -A INPUT -p tcp --dport https -j DROP
iptables -t filter -A OUTPUT -p tcp --dport https -j DROP
su -- user -c "startx" &
exit 0

/home/user/.xinitrc :

xset -dpms &
xset s off &
exec chromium -kiosk --start-maximized --disable-restore-background-contents --window-size=1280,1024 --disable-translate "http://YOUR_SITE.ru/PATH_TO_PAGE/"

Запускается Хром прямо под иксами, без оболочек, и открывает нужную страницу. Ни на какие другие сайты доступа нет. Возможности вызвать какие-то другие программы, не имея пароля администратора - тоже ;)

Под *nix обычно и имеют в виду Linux (изредка - +FreeBSD).
Зачем IT-нику знать особенности ОС, на которой крутится 90% серверов в мире, с которыми он взаимодействует? Ну незачем, пишите дырявые сервисы и запускайте их на winserver стоимостью в пару десятков тысяч рублей за лицензию, чего уж там.

Рекомендую, тут классные шаблоны и периодически появляются новые. Новые всегда под последние версии bootstrap. Бесплатно.

Маскардинг не работает в вашем случае. Добавляйте явное правило SNAT для таких пакетов.
В общем, всё выглядит примерно так.
1. LAN client -> Mikrotik, 192.168.0.100:4555 -> 1.2.3.4:87 (на роутере у этого пакета будет in-interface ether2, так как пакет действительно прилетел из локальной сети) - если в правиле указано сопоставление пакета по входящему интерфейсу для dst-nat (логичнее предположить, что он у вас указан как ether1), то никакого перенаправления не будет. Либо заводите два правила, либо не проверяете для перенаправляемых пакетов входящий интерфейс, а только адрес назначения, протокол и порт. Двигаемся дальше.

2. Mikrotik -> LAN server, 192.168.0.100:4555 -> 192.168.0.2:87 (output-interface ether2) - Победили перенаправление и пакеты теперь успешно улетают в локалку после замены адреса назначения (в том-то и суть dst-nat). Но что будет дальше? Локальный сервак получает перенаправленный через роутер пакет и отвечает на него напрямую в обход роутера.

3. LAN server -> LAN client, 192.168.0.2:87 -> 192.168.0.100:4555 - Это ответный пакет от сервера. Но клиент ожидает пакеты с адресом источника 1.2.3.4, а не эти, и отбрасывает их. Либо молча, либо явно с посылкой ICMP-сообщения.

Вот такие дела. Отсюда решение. Правила ната на микротике.
1. Правило для проброса портов из интернета:

chain = nat/prerouting,
  input-interface = ether1, 
  dst-ip = 1.2.3.4, 
  protocol = tcp, 
  dst-port = 87, 
  action = dst-nat, 
  dst-nat-address = 192.168.0.2, 
  dst-nat-port = 87.

2. Правило для проброса портов из локалки:

chain = nat/prerouting
  input-interface = ether2, 
  dst-ip 1.2.3.4, 
  src-ip = 192.168.0.0/24, 
  protocol = tcp, 
  dst-port = 87, 
  action = dst-nat, 
  dst-nat-address = 192.168.0.2, 
  dst-nat-port = 87.

3. Правило для source-nat, чтобы ответные пакеты сервера так же пошли через роутер:

chain = nat/postrouting,
  output-interface = ether2, 
  dst-ip = 192.168.0.2, 
  src-ip = 192.168.0.0/24, 
  protocol = tcp, 
  dst-port = 87, 
  action = src-nat, 
  src-nat-address = 192.168.0.1

Вот как-то так. Можно, кстати, пакеты из локалки в локалку метить в цепочке FORWARD и уже на основе метки делать src-nat.