Oto moje przemyślenia odnośnie implementacji powyższych funkcji, które były ostatnio omawiane na liście. Aby zrobić to dobrze potrzebna będzie nie mała rewolucja.
Należy rozdzielić adresy od komputerów oraz połączyć urządzenia z komputerami w jeden byt. Obecnie mamy tabele nodes i netdevices. Ja proponuję je połączyć w jedną:
CREATE TABLE devices ( -- początek zawiera standardowe pola z oryginalnej tabeli id int(11) NOT NULL auto_increment, name varchar(32) NOT NULL DEFAULT '', location varchar(255) NOT NULL DEFAULT '', description text NOT NULL DEFAULT '', producer varchar(64) NOT NULL DEFAULT '', model varchar(32) NOT NULL DEFAULT '', serialnumber varchar(32) NOT NULL DEFAULT '', ports int(11) NOT NULL DEFAULT '0', purchasetime int(11) NOT NULL DEFAULT '0', guaranteeperiod tinyint unsigned DEFAULT '0', shortname varchar(32) NOT NULL DEFAULT '', nastype int(11) NOT NULL DEFAULT '0', clients int(11) NOT NULL DEFAULT '0', secret varchar(60) NOT NULL DEFAULT '', community varchar(50) NOT NULL DEFAULT '', channelid int(11) DEFAULT NULL, -- teraz dodajemy to co było w nodes creationdate int(11) NOT NULL DEFAULT '0', moddate int(11) NOT NULL DEFAULT '0', creatorid int(11) NOT NULL DEFAULT '0', modid int(11) NOT NULL DEFAULT '0', lastonline int(11) NOT NULL DEFAULT '0', access tinyint(1) NOT NULL DEFAULT '1', warning tinyint(1) NOT NULL DEFAULT '0', -- dodajemy pole właściciela (NULL dla urządzeń "szkieletowych") ownerid int(11) DEFAULT NULL );
W tej tabeli będą wszelkie urządzenia szkieletu sieci oraz klienckie, czy to komputer, router, switch, czy bramka. Można jeszcze ewentualnie dodać pole 'type' określające właśnie co to za urządzenie. Powiązania wszystkich urządzeń między sobą przenosimy do tabeli 'netlinks', która do tej pory zawierała tylko połączenia urządzeń "szkieletowych". Pytanie odnośnie pól access i warning, czy blokowanie/ostrzeganie robimy per-urządzenie, czy per-adres? Ja bym zostawił jak tutaj, a samo blokowanie to jest sprawa na osobną rewolucję.
Jeżeli chodzi o interfejs to Urządzeniach Sieciowych nie zmienia się w zasadzie nic, w klientach mamy Listę urządzeń zamiast Listy komputerów.
Adresy urządzeń (w tym i komputerów) przenosimy do tabeli 'ipaddresses' ('nodes' też by mogło być, bo to w końcu coś więcej niż sam adres):
CREATE TABLE nodes ( id int(11) NOT NULL auto_increment, deviceid int(11) NOT NULL DEFAULT '0', -- ID urządzenia -- teraz pola które były w nodes mac varchar(20) NOT NULL DEFAULT '', ipaddr int(16) unsigned NOT NULL DEFAULT '0', ipaddr_pub int(16) unsigned NOT NULL DEFAULT '0', passwd varchar(32) NOT NULL DEFAULT '', creationdate int(11) NOT NULL DEFAULT '0', moddate int(11) NOT NULL DEFAULT '0', creatorid int(11) NOT NULL DEFAULT '0', modid int(11) NOT NULL DEFAULT '0', -- i najważniejsze pole 'nodetypeid' int(11) DEFAULT NULL );
Czyli już możemy do każdego urządzenia dopisać kilka adresów, teraz ważne jest żeby zdefiniować do czego dany adres służy i jak ma być traktowany przez backend. Tzn. czy ma być brany pod uwagę przy generowaniu DHCP, firewalla, tc
CREATE TABLE nodetypes ( id int(11) NOT NULL auto_increment, name varchar(64) NOT NULL DEFAULT '', description text NOT NULL DEFAULT '', chkmac tinyint(1) DEFAULT NULL, halfduplex tinyint(1) DEFAULT NULL, nas tinyint(1) DEFAULT NULL, dhcp tinyint(1) DEFAULT NULL, -- i tu dodać inne potrzebne flagi, jak np. firewall, tc, ident, ewx, ether, których listę należy zdefiniować dokładniej. Można by także zastąpić je wszystkie jednym polem 'flags', ale wtedy backend będzie miał trudniej (wolniej) parsować jego zawartość. Innym rozwiązaniem byłoby zastosowanie sumy binarnej, tak jak jest zrobione z typami kont. );
Myślałem, żeby łączyć nodes z nodetypes relacją jeden-do-wielu, ale takie komplikowanie nie będzie nam potrzebne. W sieciach używa się raczej ograniczonej liczby typów, poza tym typy będą definiowane przez użytkownika. Od strony interfejsu rozbudowuje nam się formularz dotyczący urządzeń klienckich, gdzie będzie wiele adresów do jednego urządzenia. Oraz dodajemy Konfiguracja -> Typy adresów IP, gdzie będzie można definiować nodetypes.
Nie uwzględniłem tutaj przypisywania klas adresowych do klientów/urządzeń. Jeśli ktoś ma pomysł na to, to ewentualnie możemy przedyskutować.