@Vladsun, тази команда е за клиента, няма как да добавиш в арп таблицата ентри с айпи/мак на някой локален интерфейс. Ядрото няма да даде това да влезе в арп таблицата (пробвай все пак, бих се учудил ако стане).

@laskov dhcp сървъра с нищо не помага, дори напротив, допринася броят на възможните атаки да нарасне  '>

Ако:

$GW_ADDR ти е ип адреса на рутера:
$GW_MAC ти е мак адреса на рутера:

ip nei add to $GW_ADDR dev eth0 lladdr $GW_MAC nud perm

Много ме съмнява да има начин да разбереш кой е производителя по какъвто и да е софтуерен начин..

Бах...грешни примери, и carp и xen не са особено юзърспейски илюстрации..

Но пък малко са приложенията, сътворени от БСД-хората, които не са порт-нати за линукс...и обратното.

openssh да речем...далеч не е нещо използвано само из бсд/линукс системите '>

бтв комерсиалните юникси включени ли са в сметката, имам и известни наблюдения върху някои от тях (за жалост повечето са отдавна) ?

Признавам че никога не съм имал много вземане-даване с БСД-та. Обаче съм чел разни писания по въпроса.

По отношение на memory management 2.6 ядрата са идеи над бсд...алгоритмите за swapin/swapout, времето необходимо за алокиране на памет, etc. особено що се отнася до netbsd.

По отношение на I/O performance нищо не мога да кажа. Предполагам много зависи от конкретния хардуер. За файлови системи няма да говоря да не сътворявам излишни спорове (ей в тва отношение обаче не знам кой би оспорил факта, че солариската ZFS е авангарда в това отношение - като интегрират LVM и ext3/reiser в "128-битова" файлова система с толкова чудни възможности в линукс/бсд да се обадят).

Мисля, че трединг-а при линукс (2.6, NPTL) е по-добър в линукс отколкото при бсд. За това ако някой е по-запознат нека ме поправи '>

По отношение на network stack-a бсд-тата показват по-добра производителност. Особено по отношение на разни филтъринг и нат цели. Най-малкото connection tracking-a под линукс е едно доста претрупано и не особено логично на моменти, но и работещо решение. Чел съм разни писания, че една машина, чиято цел е да препраща пакети базирано на статични рутинг имала почти 60% по-добра производителност без conntrack (беше отдавна и не съм абсолютно убеден в цифрата...а и сега може да са оптимизирали кода).

По отношение на подържан хардуер, нещата са ясни и не са в полза на БСД-тата.

По отношение на userspace-a едва ли някой може да ти прави обобщения. БСД имат някои много добри техни решения. Примерно carp (obsd).  Линукс тоже (xen да речем).

Цялостната картинка е повод на много спекулации. Както казах, зависи какво целиш. Ако искаш да си пускаш load-balancer или firewall или пък публично-достъпен http server (за статично съдържание), БСД-тата примерно биха свършили по-добра работа. Ако искаш да си пускаш application server (особено за java-базирани приложения) ми се вижда глупаво да не предпочетеш линукс. За домашна употреба, също не виждам причина да си сложа БСД (не съм типа слакаджия дето обича да бърника по цял ден и да имам много свободно време - простете ми намека, не целя негативизъм).

Но като цяло нещата са прекалено комплицирани, за да може човек като мене да ти даде "цялостно" компетентно  мнение. Също така не бих те посъветвал да се вслушваш в разни хора, които дават категорични мнения без да познават добре нито едната ОС '>

По отношение на какво да е по-добър или по-лош?

Ако:

$GW_ADDR ти е ип адреса на рутера:
$GW_MAC ти е мак адреса на рутера:

ip nei add to $GW_ADDR dev eth0 lladdr $GW_MAC nud perm

[Цитат]

Ахм...почти си успял '>
Пробвай така '>

съдържание на скрипта:

Цитат

#!/bin/bash IPTABLES=/sbin/iptables $IPTABLES -P INPUT ACCEPT $IPTABLES -F INPUT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F OUTPUT $IPTABLES -P FORWARD DROP $IPTABLES -F FORWARD $IPTABLES -t nat -F $IPTABLES -A FORWARD -i eth0 -o eth2 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT $IPTABLES -A FORWARD -i eth2 -o eth0 -j ACCEPT $IPTABLES -A FORWARD -j LOG $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE $IPTABLES -A INPUT -i eth0 -m state --state INVALID -j DROP $IPTABLES -A FORWARD -i eth0 -m state --state INVALID -j DROP $IPTABLES -t nat -A PREROUTING -p tcp -i eth0 --dport 30555 -j DNAT --to 192.168.0.2:30555 $IPTABLES -t nat -A PREROUTING -p udp -i eth0 --dport 30555 -j DNAT --to 192.168.0.2:30555

Проблемът идва оттам че режеш всякакви пакети, които установяват връзка от външен хост към хост от мрежата (а ти това целиш с тези две ДНАТ правила).

[Цитат]

Цитат

Е-ееее, ти пък ... Недей така, де - напоследък много постове пускаш на тема "Dist/OS vs. Dist/OS"

Просто си изказвам предпочитанията, нямам нищо против чуждите '>

Ами има си BSD-подобни и sysV-подобни инитскриптове.

Аз лично предпочитам sysv инит скриптовете. Много по-лесно се спират/пускат/рестартират отделни демони.

Но пък слакаджийте са хора, които не ги мързи да си трошат пръстите и времето, така че щом им харесва си е тяхна работа.

А какво му пречи да си поискаш адреса и настройките през DHCP когато си решиш, да не би да ти е фатално нещо че не е станало точно когато са ти минали init скриптовете?

Да не би да boot-ваш от мрежата с нещо от сорта на kernel level network autoconfig, да си зареждаш евентуално файловата система от отдалечена машина?  Единствено ТОГАВА процеса на вземане на мрежови настройки минава преди всички скриптове от rcX.d

В противен случай не виждам абсолютно никакъв проблем при теб, стига си оплаквал света, ами си виж инитскриптовете '>

Предполагам ползваш PAM...

виж /etc/pam.d/login и /etc/security/time.conf (нещата се описват в малко неудобен вид)

Иначе сам по себе си login няма такава функционалност. Няма какво да търсиш в /etc/login.defs, а и голяма част от параметрите там или се override-ват или са излишни заради PAM.

И внимавай докато си играеш с тези двата файла..винаги си дръж една оставена лог-ната root-ска конзола докато не се увериш че нещата са наред. Възможно е да стане кофти издънка без да искаш '>

За да бъдем коректни:

1) Да, MAC адресът принципно се сменя през ifconfig.

2) Не си прав, DHCP сървърът най-вероятно си "говори" с теб. Ако беше прочел необходимото RFC щеше да видиш че това е протокол работещ върху UDP а не върху ethernet. Това е правено с цел да работи и върху мрежи, различни от етернет-базираните. Има и нещо, наречено ip broadcasting, което е различно от подобното понятие в света на OSI layer2.

3) Естествено, ако в DHCP сървъра е казано твърдо "за този мак адрес->това IP", няма да си получиш IP-то.

4) Има разбира се и вероятност някой на DHCP сървъра да се е разиграл с iptables/ebtables и да не иска да си комуникира с "непознати" айпи адреси, което е малко вероятно едно на ръка защото не е никакъв проблем да се spoof-ват, и две на ръка защото това утежнява администрацията.

Bogo, интересна позиция имаш...

Ядрото според мен надали е проблема. Може лесно да се провери ако буут-не в single-user mode (runlevel 1)..Убеден  съм че ще може да си ползва клавиатурата в tty-то си там..

Напоследък заради собственото си малоумие да се занимавам с неща с които не съм добре запознат, се натъкнах на приятни драми свързани с ядрото и клавиатурите. Но специално за PS/2 клавиатурите нещата са доста прости и ясни и няма как да има такива проблеми...виж с USB нещата се усложняват приятно '>

Според мен има някакъв проблем свързан с X сървъра...95% съм убеден в това даже '>

[Цитат]

Цитат

Според мен линукс хлапето е по-готино , по-умно и по-интелигентно от уиндоус хлапето.

А пък според мене има повече сексуални дисфункции от сорта на преждевременна еякулация.

Но има ли значение след като уиндоус се РАЗРАБОТВА ОТ ШИБАНИ НЕГРИ!!!!!!!!!!