I've just discovered the wonder that is iPXE.
Im running various versions of Debian on many different computers, and would like to remotely tell them to reboot into iPXE, and have iPXE automatically boot into a clonezilla auto-deploy .iso I have.
Is there a way to tell Linux to automatically boot into iPXE on next boot once, and have iPXE then automatically boot into an .iso from a server?
i'd like to hack together my own little script to parse conntrack data, to get customized network information from some Linux boxes that are also NAT routers.
an example of a line from the conntrack tables is:
ipv4 2 tcp 6 300 ESTABLISHED src=1.1.1.2 dst=2.2.2.2 sport=2000 dport=80 src=2.2.2.2 dst=1.1.1.1 sport=80 dport=12000 [ASSURED] mark=0 use=2
all those fields have been described elsewhere, but I can't find any information on the very last column (use=2, but usually use=1).
while planning my script, it has occurred to me that the exact same IP/port combinations might in theory repeat themselves - i.e. get opened, pass some data, get closed, and after a while get opened again.
Might this "use" column indicate that this ip/port combination has already been seen before? If so, in what timespan?
At a remote location, there is a chinese ethernet enabled POS printer.
It somehow garbled it's configuration, and its self-test now says that its IP address is 253.100.156.93, (which is inside a IANA reserved block)
No biggie, I thought - I will just ifconfig eth0 add 253.100.156.92 and log into the printer's config panel and reset the IP.
Strangely, after adding that IP address, ifconfig still doesn't show it.
ip a does, though:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:27:0e:1d:07:ed brd ff:ff:ff:ff:ff:ff
inet 192.168.209.99/16 brd 192.168.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 253.100.156.92/32 scope global eth0
valid_lft forever preferred_lft forever
but i still can't ping or visit 253.100.156.93.
Is there something I am missing? Why does ifconfig not show that address, but ip a does? Is there some built-in filtering of reserved IANA addresses in the kernel?
So, I have a server that also does NAT (masquerading) for my LAN, and forwards all internet traffic to a gateway.
I need to know who in my LAN is visiting what websites. I don't want to go the whole SQUID proxy route.
I (very surprisingly?) couldn't find any software that does this easily.
AFAICT, /proc/net/ip_conntrack should have all information I need, because all my LAN's connections go through the NAT.
So I hacked together a small script that simply DNS-resolves all the entries in ip_conntrack, and log them.
My plan was to simply do a 'tail -f /proc/net/ip_conntrack |my_script.pl', and be done with it, but tail-f doesn't seem to work on that file? It dumps out a lot of lines, and then stops.
How can I get every new connection that is NAT'ed on my server in realtime? Have I missed a ready-made software that simply tells me who on my LAN is talking to which server on the internet, via this NAT?
So I have a OpenVPN server (10.0.0.1), and several OpenVPN clients connecting to it. The server authenticates via certificates and keys generated by easy-rsa, and hands out a unique IP (10.0.x.1) and some basic routes via ccd/ files. Works great!
But I'd like to have another spare OpenVPN server (e.g. 10.0.254.1) somewhere else, and have the clients connect to that server in case the main server goes down. This is very easy by just specifying multiple servers in the clients config file.
However: - is it really ok to simply copy or rsync the main servers certificates and keys to the backup server? It works, but feels very hack-ish. - I would like the main and the backup server to be connected to each other by a OpenVPN link, too.
Here's the tricky bit: I would like clients that are connected to the main server to be able to talk to clients that are connected to the backup server. i.e.: If, for some reason the client 10.0.1.1 is connected to the primary server 10.0.0.1, and the client 10.0.9.1 is connected to the backup server 10.0.254.1 (even though it should usually be connected to 10.0.0.1), how can the main and the backup server figure out the routing dynamically?
If I, for example, have the two servers connected via a seperate OpenVPN instance. Is there a clean way for the backup server to let the main server know "hey! 10.0.9.1 just connected to me, so you should route anything for that IP through me!" - and to have all that routing fix itself once the clients decide to connect to the main server, again?
Yesterday, I added a second 500GB hard drive to a system. This system was installed as a RAID-1 system with only one drive, because I didnt have the other one on hand.
After finally adding the second disk, I ran "sfdisk -d /dev/sda | sfdisk --force /dev/sdb", as i have done very often.
Then I ran "mdadm --add /dev/md0 /dev/sdb1", and the RAID started syncing.
After it was finished, it turned out the new partitions were added as spares, and not as active devices. This seems to have happened because the RAID 1 device thought it only had space for 1 active device, because of the strange installation I did.
So, today, I ran "mdadm --grow --raid-devices 2 /dev/md0" (note I didnt put a '=' before the '2').
Immediatly, my whole filesystem dissapeared!
I am still logged into an ssh session, but I am limited to bash's built in commands, which is rather painful.
I made up a bash-builtin-cat-command, and can still cat some files. /proc/mdstat looks fine and dandy, and indicates that the new drive is now actually active.
/var/log/messages (which, strangely, is still accessible even though all other files are not) gives me thousands of:
attempt to access beyond end of device md0: rw=0, want=868055984, limit=4
(the number after 'want' varies). The messages were all generated in a couple of seconds after running mdadm --grow, and then stopped.
As mentioned, this is a remote machine.
So I have a Debian 7 server with 3 hard drives. Its RAID-1 is basically configured this way:
md0: sda1, sdb1 --> / (root) md1: sda5, sdc1 + sdb5 (spare) --> /data (sdc1 is on a SSD, and sda5 is marked 'writemostly').
both sda and sdb have grub installed on them.
When installing an extra network card, I messed up and unplugged sdc's data cable (note that sdc doesnt have GRUB or /, and should have nothing to do with booting).
So the system booted fine after that. I noticed my error, shut down the machine, and plugged sdc back in (while mdadm was rebuilding md1 on the spare).
Now, the system either gave me the dreaded GRUB shell, or just a black screen with a blinking cursor. depending on which hard drive(s) I unplugged. But no combination of hard drives gave me a successful boot. I also tried it with having all 3 drives connected, and telling the BIOS to boot from any of the boot drives manually.
What I did in the end was to boot Debian setup in rescue mode, aassembled the RAID devices, and let them rebuild.
This didn't result in a successful boot.
So I booted rescue mode again, and manually re-installed GRUB on sda and sdb. This fixed my problem.
My question is: what happened here? a) sdc shouldn't affect booting in any way, AFAIK? b) even if something of the RAID rebuilding process I interrupted would affect booting, why did the system not boot after I rebuild the RAID arrays in rescue mode? Why did I have to re-install GRUB on sda and sdb manually, if, as far as I understand, the sectors on the drives that house GRUB dont have anything to do with the RAID arrays?
So I got an abuse complaint for one of my dedicated servers, running Debian 6.0
Sure enough, sometimes, top shows /usr/bin/host using a lot of CPU for no apparent reason, and netstat shows process host doing a lot of HTTP requests.
After while, my syslog even says nf_conntrack: table full, dropping packet., which i assume has something to do with this matter.
I have verified the executable /usr/bin/host using debsums, and is seems to be fine, too. The server as such is 100% updated, too.
So i am guessing something is somehow calling my host executable and coercing it to do HTTP requests for some DDoS.
I could of course simply hack together a script to killall host as soon as this is happening, but I would really like to know where the problem originates from.
I am checking the Apache logs for interesting entries around the time that host is starting to do its requestst, but haven’t found anything yet.
Anyone have a recommendation on what else to do? How can I see who and what called 'host'?
Google didnt show up any examples of /usr/bin/host being abused, at all!