Many public git repositories have several alternate URLs; for instance, the kernel.org repositories have git://, https://, and https:// URLs.
The common URL schemes for git repositories are:
ssh:// – default port 22
git:// – default port 9418
https:// – default port 80
https:// – default port 443
Above list gives you the respective ports which needs to be kept open on the firewall to be able use your Git repositories.
The git:// protocol uses port 9418, so you should make sure your firewall allows outbound connections to this port.
If you use csf ensure this port is enabled in TCP_IN and TCP_OUT.
To test if the git:// is working you can try the following command on the server
netstat -ntpl|grep -i 9418
To test it externally you can telnet to the port for the respective server’s ip.
Strange the way I was continuously blocked by my server for port scanning. Never realized that a tiny little extension of nagios attached to Google Chrome could be this much heart throbbing. Little did I realize that the settings to check for updates set to 1 mins could kick me off from the shell permanently. CSF that keeps a check on intruders found the owner himself to catch this time.
It was really crazy day-by-day and started recreating the issue by hopping into logs, figuring that the request coming back to a specific port on my desktop has been the route cause.
Hey listen, I don’t download things with torrent so often. Then what else that could be bothering so much? The google search points to a harmless creative entertainer on my desktop ‘banshee’s daap plugin and there I go, disabled and even removed the extensions connecting to external world.
No go at all! Here it blocks again. Lets block the incoming port on my desktop. UFW -uff yeah , never used to turn it on before but no go. Put a red signal and say – never come back again. It was just about to scream out louder. Realized that the name that I use to connect no more pings back to my server. It goes on to the cloud and lives for ever on cloud. – Yes, the tiny little change that was made to my domain. CloudFlare has taken over my DNS and I no more control the way my names work.
All that I had to do is to provide the ip instead of random dns name to get off the hook of CSF and continue browsing.
– Finding it funny and not clear – I was in the same condition when I started fixing this issue. You might figure it out little later. Keep reading.
Tags: cloud, cloudflare, csf, daap, linuxmint, Nagios, ufw
If you install CSF on your server along with Mod_security you might see it blocking google bot for some specific rules. At times you might find it offensive to remove some of the mod_security rules from the configuration just to allow Google bots.
Here is what you should be doing to make Google Bots crawl through your sites again.
Just add the following rules to mod_security configuration file and restart apache.
# GoogleBot by user-agent…
SecRule HTTP_USER_AGENT “Google” nolog,allow
SecRule HTTP_USER_AGENT “Googlebot” nolog,allow
SecRule HTTP_USER_AGENT “GoogleBot” nolog,allow
SecRule HTTP_USER_AGENT “googlebot” nolog,allow
SecRule HTTP_USER_AGENT “Googlebot-Image” nolog,allow
SecRule HTTP_USER_AGENT “AdsBot-Google” nolog,allow
SecRule HTTP_USER_AGENT “Googlebot-Image/1.0″ nolog,allow
SecRule HTTP_USER_AGENT “Googlebot/2.1″ nolog,allow
SecRule HTTP_USER_AGENT “Googlebot/Test” nolog,allow
SecRule HTTP_USER_AGENT “Mediapartners-Google/2.1″ nolog,allow
SecRule HTTP_USER_AGENT “Mediapartners-Google*” nolog,allow
SecRule HTTP_USER_AGENT “msnbot” nolog,allow
Tags: cpanel, csf, GoogleBots, mod_security, SEO
Unable to add a new block for an ip via CSF? Iptables modules are not loaded into your server’s kernel.
If you’re getting the following error on a OpenVZ VPS server:
iptables: No chain/target/match by that name
ACCEPT udp opt — in !lo out * 0.0.0.0/0 -> 0.0.0.0/0 state NEW udp dpt:953
Contact the DC to make a small change in OpenVZ iptables configuration in
/etc/vz/vz.conf as follows:
IPTABLES=”ipt_REJECT ipt_tos ipt_TOS ipt_LOG ip_conntrack ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state iptable_nat ip_nat_ftp”
Once this line is added, they will restart your vps or all vps nodes on the hardware node will be restarted to make iptables modules available.
This should resolve the issue.