Smokes your problems, coughs fresh air.
In August 2011, probably while procrastinating learning for my university admission exams, with one mouldy foot still in my IT-past, I signed up for Security Override, an online game designed to turn network security n00bs such as myself into novices.
I’ve never dedicated the 20 hours to learn anything to the game, which I should have spent Josh Kaufman to ascent my n00b-state, but I nevertheless had some solid fun with it. 🙂
Aaron Clauset, Cristopher Moore and M.E.J. Newman published a paper in Nature about the automatic extraction of hierarchical structure of networks: Hierarchical structure and the prediction of missing links in networks. There’s a free PDF of the paper on Mark Newman’s personal website.
In the abstract the say that their results suggest that hierarchy is a central organizing principle of complex networks, capable of offering insight into many network phenomena.
This is of interest of a pet project of mine that I haven’t spent much time on in recent years, but may again in the future.
I’m rummaging through my old bookmarks… More to come.
When clustering machines, you make it possible for a failover node to be accessible on the same address as the primary node by having a virtual network interface. In Debian, you can add one like this:
iface eth0:0 inet static address 192.168.1.75 network 192.168.1.0 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.251
By leaving out the auto eth0:0, I prevent the interface from becoming active automatically. I can do “ifup eth0:0” to enable it. This can also be left to clustering software, but clustering software can also get in the way, so often you just want to do it by hand.
You can easily scan the entire network for machine presence with nmap:
nmap -sP -v -v 192.168.1.*
It also supports list scanning, which I have yet to investigate.
I’m always confused about which wiring scheme to use for UTP cables. After doing some research, it seems T568B is what you need. Wikipedia says that is doesn’t really matter, but crosstalk can be a problem for T568A in some esoteric situations:
Note that the only difference between T568A and T568B is that pairs 2 and 3 (orange and green) are swapped. Both configurations wire the pins “straight through”, i.e., pins 1 through 8 on one end are connected to pins 1 through 8 on the other end. Also, the same sets of pins are paired in both configurations: pins 1 and 2 form a pair, as do 3 and 6, 4 and 5, and 7 and 8. However the different pairs in an Ethernet cable are identical,[dubious – discuss] so one can use cables wired according to either configuration in the same installation without significant problem; problems involving crosstalk can occur (which is normally minimized by correctly twisting a pair together), but are usually insignificant in all but the most stringent specifications such as Category 6 cable. The primary thing one has to be careful of is not to accidentally wire the ends of the same cable according to different configurations (except if one intends to create an Ethernet crossover cable).
When you run virtual machines, the most convenient network setup is having a bridge between the virtual machine and your normal ethernet network. In Debian, I use the following config in /etc/network/interfaces to have such a bridge:
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) # The loopback interface auto lo iface lo inet loopback # The first network card - this entry was created during the Debian installation # (network, broadcast and gateway are optional) auto eth1 iface eth1 inet manual auto br0 iface br0 inet static address 192.168.1.101 network 192.168.1.0 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.100 bridge_ports eth1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off
In this setup, the br0 gets the IP address that eth1 had before. Intuitively, I would have created a bridge which would connect eth1 and new interfaces, but when I did that, I could not get it to work.
I then used a command similar to this to install the virtual machine:
virt-install --connect qemu:///system -n vm10 -r 512 --vcpus=2 -f ~/vm10.qcow2 -s 12 -c ~/debian-500-amd64-netinst.iso --vnc --noautoconsole --os linux --os-variant debianLenny --accelerate --network=bridge:br0 --hvm
You can adjust where necessary. What’s important, is the –network=bridge:br0. This makes sure that kvm is run with:
kvm [more options] -net nic,macaddr=54:52:00:52:1c:7c,vlan=0,model=virtio -net tap,fd=7,script=,vlan=0,ifname=vnet0
The network setup looks like:
br0 Link encap:Ethernet HWaddr 00:15:17:23:83:67 inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe23:8367/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1866633 errors:0 dropped:0 overruns:0 frame:0 TX packets:1678602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:892540330 (851.1 MiB) TX bytes:971936093 (926.9 MiB) eth1 Link encap:Ethernet HWaddr 00:15:17:23:83:67 inet6 addr: fe80::215:17ff:fe23:8367/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13371212 errors:0 dropped:0 overruns:0 frame:0 TX packets:12703312 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4234365756 (3.9 GiB) TX bytes:201738186 (192.3 MiB) Memory:88180000-881a0000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2672817 errors:0 dropped:0 overruns:0 frame:0 TX packets:2672817 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:493599313 (470.7 MiB) TX bytes:493599313 (470.7 MiB) vnet0 Link encap:Ethernet HWaddr 00:ff:2d:a0:76:34 inet6 addr: fe80::2ff:2dff:fea0:7634/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:159072 errors:0 dropped:0 overruns:0 frame:0 TX packets:310906 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:10860687 (10.3 MiB) TX bytes:465526222 (443.9 MiB)
© 2024 BigSmoke
Theme by Anders Noren — Up ↑
Recent Comments