commandlinefu.com is the place to record those command-line gems that you return to again and again.
Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.
If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/
You can sign-in using OpenID credentials, or register a traditional username and password.
First-time OpenID users will be automatically assigned a username which can be changed after signing in.
Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.
» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10
Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):
Subscribe to the feed for:
this alternative shows the differences as they occur so that they are made plain
Rather then editing the /etc/sysconfig/iptables file, or during a kickstart doing some awk/sed magic, easily add a rule in the correct place within iptables
If you changed the default policy on any chain other than filter table chain's, this won't be enough.
To save all rules so that they are not lost in case of a server reboot:
/etc/init.d/iptables save
a simple command in order to make iptables rules permanent, run @ sudo!
Destination IPs will become invisible to source IPs!
edit the /etc/sysconfig/iptables file and try to work whit this:
-A INPUT -i (interface) -m mac (mac address) -j ACCEPT/DROP
This will allow you to watch as matches occur in real-time. To filter out only ACCEPT, DROP, LOG..etc, then run the following command: watch 'iptables -nvL | grep -v "0 0" && grep "ACCEPT"' The -v is used to do an inverted filter. ie. NOT "0 0"
Stores the currently active iptables rules to a file that will be applied upon reboot
If you don't save the rule set it won't be applied during a reboot
Stuck behind a restrictive firewall at work, but really jonesing to putty home to your linux box for some colossal cave? Goodness knows I was...but the firewall at work blocked all outbound connections except for ports 80 and 443. (Those were wide open for outbound connections.) So now I putty over port 443 and have my linux box redirect it to port 22 (the SSH port) before it routes it internally. So, my specific command would be:
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 22
Note that I use -A to append this command to the end of the chain. You could replace that with -I to insert it at the beginning (or at a specific rulenum).
My linux box is running slackware, with a kernel from circa 2001. Hopefully the mechanics of iptables haven't changed since then. The command is untested under any other distros or less outdated kernels.
Of course, the command should be easy enough to adapt to whatever service on your linux box you're trying to reach by changing the numbers (and possibly changing tcp to udp, or whatever). Between putty and psftp, however, I'm good to go for hours of time-killing.
Removes an iptables rule created by fail2ban. This example shows how to remove a rule for an IP from the fail2ban-SSH chain. Can be used for any service monitored by fail2ban.
For more on fail2ban, see http://www.fail2ban.org/wiki/index.php/Main_Page
This turns your iptables packet filter to a "Allow any from any to any" filter, so you can rule out any filtering issues when you have a problem to enable a connection from or to your host.
To re-enable it, run /etc/init.d/iptables restart