Перейти к содержанию

Hans R. Steiner

Members
  • Постов

    1822
  • Зарегистрирован

  • Посещение

Весь контент Hans R. Steiner

  1. Великолепно поставленый вопрос. Очень подробный и содержательный. Это эталон того, как надо задавать вопросы. В свою очередь, считаю себя просто обязанным дать такой же полный и исчерпывающий ответ: http://google.ru http://yandex.ru http://rambler.ru http://www.linux.ru/forum/index.php?t=search
  2. могу, но не буду... для этого гугл есть и много-много-много различной документации
  3. route add default gw ${DEFGW} echo 0 > /proc/sys/net/ipv4/ip_forward
  4. 1. Перенос пакетов, а точнее, сборка уже откомпилированного -- пакета в пакет Slackware Linux, дла последующей инсталляции -- при помощи installpkg, может проводится (что рекомендуется) -- утилитой checkinstall. 2. Цитата: Смысла мне компилировать какой либо пакет на урезанной версии нет, эт мне придется средства разработки ставить и еще чегонибуть опять значит получается ставить лишнее а потом сносить, не ВЫХОД. -- Ничего не понял... 3. Цитата: 2 И ядро. Если у меняя всего по минимуму Может есть смысл поставить ядро ванильное? Вопрос: Собрать его на другой машине а как потом перенести на ту которая поменьше? -- см пункт 1
  5. Да... в данном случае, наиболее правильным, будет поднятие слейв-DHCP-серверов с мастером в сердце сети
  6. DHCP vs Static IP плюсы: в больших сетях, автоматическая выдача параметров сети клиенту удобна с той точки зрения, что при внесении изменений в агхитек- туру сети или просто изменение IP-адреса клиента, сводится лишь к внесению этих изменений и правку конфига dhcpd, что позволяет избавится от обзвона абонентов и просьб сменить IP на новый. Другими словами, DHCP - это хороший инструмент для управления сетевыми настройками клиентских машин из одного файла. минусы: Не смотря на удобство DHCP, у динамической раздачи параметров по сети, есть свои минусы. Основными минусами, с которыми администратор сталкивается в больших сетях, использующих DHCP, являются не граматная установка файерволов на клиентских машинах и возможность появления ложных DHCP-серверов.
  7. на сколько я знаю, стандартный механизм распределения рав такого не поддерживает... имхо, смотреть надо в сторону quote или таких систем, как lids... когда-то давно, я натыкался на подобную тему, может быть, даже и на этом форуме... кажется, там через квоту проблему решали... но не уверен...
  8. дорваться до файла...
  9. Не просто старо, а безнадежно устарело :/
  10. может быть, от имени root попробывать?
  11. Эх... без ошибок было бы лучше (хотя, сам с ошибками пишу ) Звук, думаю, что поддерживается... а вот все остальное... без эксперемента не понять
  12. А я надеялся прочитать, куда новел их послали....
  13. Так... ладно... я спать... если что, будите
  14. А кто мешает девиц-красавиц ссобой взять?
  15. Цитата: ибо мало кто из работодателей отличает програмиста от инженера системщика, администратора БД или системного админитратора. Печальная, но правдивая история к сожалению, это действительно так и это очень сильно отражается на ЗП но с этим надо бороться... ЗЫ: как бы, уже давно существует правсоюз системных администраторов. Цитата: так что некая универсальность никому не повредит, тем более что линукс ум в порядок приводит не хуже математики так что пока молод и нет семьи вперед и с песней! Ну тут вопрос в "надо" и "можно" а вот касательно работы... я линух увидел уже работая... а когда начал работать с линухом (в смысле, за деньги... по работе), это только стимулировало его изучение...
  16. Хочу пива... уже две или три недели хочу пива... ...а вот пить его нескем... Если сурьезно: реально, за две-три недели, устал просто не по детски и только о пиве и мечтаю... а кому ни позвони, все либо заняты, либо заняты, либо заняты... исходя из всего этого, есть предложение: Всем желающим, сегодня в суботу, где-нибудь собраться и попить пива, поговорить... в общем, отдохнуть... Контакты: DELETED!!!
  17. Как зачем? висеть в ОЗУ - это и mod_perl умеет... с него и началось (хотя, могу и ошибаться... наверное, все же с какой-нибудь явы началось) у бинарников есть, как минимум, одно преимущество - они бинарники т.е., они не удобочитаемы и код скрыт от глаз простого человека. Что это дает? 1. даже при получении доступа к такому скрипту-бинарнику, человек -- не сможет его разобрать и получить какую-либо информацию. -- (ну... может какую-нибудь все-таки и получит, но по своему -- опыту могу сказать - дизасм и дебагинг - ужас и кЩмар) 2. если говорить о коммерческих проектах, которые планируются -- продаваться и продаваться неоднократно т.е., много раз и за -- деньги (движек для сайта, форума или еще чего-нибудь), можно -- быть увереным, что никто не выдаст код как свой и не будет -- получать за него деньги, кроме как его владелец. 3. при распространении программного продукта в бинарниках, а не -- в исходниках, меньше шанс использования его дырявости -- поклонниками ксакепа т.е., пока не вуйдут публикации на -- конкретную тему, напакостить может только человек, хоть как-то -- но подгатовленый...
  18. Trulala писал(а) Птн, 31 Марта 2006 11:52 stavte suse. stabilni xoroshui distributiv. a vobshe windows dla chainikov et utverjdeniye nepravilnoye programistu nada znat obe systemi. Хм... интересно, а зачем программисту Windows-приложений, который пишет на тех же дельфях или на каком-нибудь вижал васике, знать OS Linux??? Это утвегждение столь же верно, что - "каждый гонщик F1, должен уметь летать на самолёте"
  19. Вообще, если требуется контроль каждого IP то, лучше создать отдельные табллици для каждой из подсетей ( чтобы было легче ориентироваться... в больших таблицах ковыряться не удобно ) и дальше, написать скрипт, который будет работать с каждым из IP или с их группой... при таком варианте, будут статические и не расползающиеся списки правил... всегда знаешь, где и что лежит... и к тому же, получается давольно гибкая система... можно свободно делать что-то типа 172.16.0.1 -j DROP 172.16.0.2 -j ACCEP 172.16.0.3 -j DROP 172.16.0.4 -j DROP 172.16.0.5 -j ACCEP 172.16.0.6 -j DROP 172.16.0.7 -j DROP 172.16.0.8 -j ACCEP 172.16.0.9 -j DROP ну естественно, это только пример... правила можно наворотить как угодно... особенно, если речь идет о какой либо статистике то, этот вариант, на мой взгляд, оптимален...
  20. iptables -A FORWARD -s 172.16.9.0/24 -j ACCEPT iptables -A FORWARD -s 172.16.0.0/16 -j DROP
  21. А у меня опера его нормально показывает
  22. Хм... надо будет глянуть этот компилируемый PHP... только вот не пойму... бинарники-то с него получить можно?
  23. Не совсем... вместо фантазии, вполне хватит забыть прикрутить PHP или просто ошибиться в расширении файла (или в DocumentIndex) ограничивать доступ к cgi-bin нужно в любом случае, а вот ограничение доступа к htdocs может привесити к неожиднным проблемам
  24. Да! Хочу поделиться советом! Не советую! Ни в каком варианте! ЗЫ: до тех пор, пока по работе именно livecd не понадобится... ЗЫ: учится на них, имхо, не следует...
×
×
  • Создать...