rvt

@admins: Is there anything in the error logs? Research suggests that cPanel error logs are stored at: /var/cpanel/logs/*.

In short, mod_evasive isn't everything it is advertised to be. If I recall correctly when looking at it before, it doesn't work well in a shared hosting environment because of how the Apache logging system works. In reality, it is a way for hosting companies to say, "We have custom anti-DOS protection which stops 90+% of DOS attacks against us." Glad you found something though. For future reference, if you (or anyone) is getting DOS'ed, it will ALWAYS show up in the access logs. If you start getting DDOS'ed (where it is distributed across hundreds or even thousands of IP's), then looking at the logs can be very challenging because the attack is spread out across a bunch of IP's making it harder to track.

Check the access logs. Perhaps this is along the lines of a DOS attack? Given that adjusting the max clients helped this issue, that is where my gut tells me to start looking.

Based on the Documentation (http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/EditZone) it is probably best to change it WHM. It's probably doable the other way but why take chances. My opinion, give djbob a couple days, maybe until next week or so, and if not addressed by then manually edit the zone file and see what happens. Note that "editing the zone file" involves more than just changing the line with the IP address on it.

Correct, there should be thousands of zone files, 1 for each domain in your DNS. Presumably with thousands of accounts there would be thousands of domains. I don't know if WHM gives you the ability to change system defined zone records. I looked to see if I could modify similar records in cPanel and was unsuccessful. You need some place that lets you modify records for .heliohost.org domains though.

This would be the problem step. I have no clue how to change the DNS records; you can't just change bind.conf because it's managed by cPanel. For that matter, the bind.conf (or, more commonly named.conf for other server admins) just contains the configuration for how the DNS server should run, not all the zone files. If you take a look in it (SSH,user@stevie# less bind.conf opens it for reading only so no harm), you should see something that says zone "wiki.helionet.org" in { type "master"; <----This line will differ based on the server you look at. You need to modify the one on the server that says master file "some file location"; //maybe some other stuff here } *Note: above layout may be slightly different, I wrote that from memory and didn't consult my working set up. The important part is that file "some file location". Somewhere near the top of the file you will most likely see a line that reads: directory "/var/named"; (actual file path might be different) This is essentially defining the base path for all the DNS files. Look for a file with the name given in that zone. When you find it, let me know because that is what we need to modify. --------------------------------------------------------------------- Alternatively, I WHMCS might have some sort of DNS manager in it that you can use to change the DNS records of domains in such. Since I try to avoid WHMCS at all costs, I can't tell you definitively if it does or does not.

Modify Apache configuration file to point the domain wiki.heliohost.org to a specific spot in the server file structure (normally /var/www/wiki.heliohost.org/public_html or something like that), then move the appropriate files to that location. Restart Apache so new configuration file take affect. Then, change DNS records to point the subdomain to Cody's IP.

ns1 is on Cody and ns2 is on Stevie, right?

I don't understand why this is something that HelioHost has to buy/pay for. The free version (http://ecocms.com/1_4_Download-CMS-System-for-Free.html) you just download the ZIP file to your computer, extract it, and away you go. Presumably the paid version is the same way (although I didn't shell out money to find out). Look, here it is on Johnny with no money out of pocket from me or HelioHost: http://thh3.thehosthelpers.com/ecocms/. This took me 3 minutes. Why should HelioHost have to pay for your development suite?

My opinion: If my site(s) need more space than the 250mb allocated, it is time to look for hosting elsewhere. If you have that much space taken up with just your files and such, you need to look at how your site is designed and change it. There is no way any user of your site will want to load 200+mb of files. Heliohost is great for development and startup websites, but by the time you get enough traffic to have filled up your space allocation, it is time to look at paid hosting elsewhere.

Works fine for me. Loads Apache's default directory listing. I can see folders of apps/, cgi-bin/, images/, and socialinterview/ along with a file postinfo.html. The apps folder contains an index file running phpInfo(), cgi-bin is empty, images is empty, and socialinterview loads another phpInfo(). I suspect with time it will work for you as well. Just because you flushed your local DNS does not mean that your DNS servers (normally managed by your internet service provider) has gotten the necessary updates. Based on the serial of your DNS records, I would speculate that this domain just got added to DNS recently (most likely in last 8 hours) and since TTL is set to 1 day, it hasn't propagated to all name servers yet. Patience.

It should be noted that this is impossible to set up on Heliohost.org or user's with *.heliohost.org subdomains. It is also a real pain if you use an extra domain. Reason: You must change your DNS settings to point to cloudflare's DNS servers so that they can direct user's to the closest cached content (to increase load times). Since HelioHost subdomains are dependent upon being able to update DNS as new accounts are created, DNS records will not be created for new accounts on Cloudflare's DNS infrastructure. Hence, these sites will not come online because of a lack of DNS records. CloudFlare does not "resync" with other name servers on a daily/hourly/weekly/whatever basis so an admin would have to manually go in and add all subdomains to the DNS system on a daily basis. Setting up Cloudflare with an extra domain is difficult because of DNS requirements. When using Cloudflare's DNS, it does not point directly to your account here at cPanel. This means that cPanel throws a fit when you try and add your domain because it does not point to the IP address of your account here. Since admins here are not willing to add exceptions in /etc/ip.remotedns to allow for Cloudflare's DNS, setting up domains here can take forever. Pretty much, end user must switch to HelioHost name servers or at least set up A records pointing to the appropriate IP address here. Then once waiting 24 hours for DNS to propagate they can add their domain and wait 48 hours. Finally, transfer their DNS back to CloudFlare and wait another 24 hours for DNS to propagate. Helionet will not work as intended with CloudFlare because of dynamically changing content (posts, server load graphics, etc).

I didn't need you to add the domain for me, I needed you to add my remote DNS servers to the file /etc/ip.remotedns so that it would allow me to add my extra domain. Nevermind then. I'll just wait.

I'm trying to set up a proof of concept with this to see how it works with forums and non-forums on HH's system. However, cPanel is crying like a kid who just lost his balloon and won't let me add my test domain as an addon domain. Can someone with root access on the server address this error: Error from park wrapper: Using nameservers with the following IPs: 208.76.62.100,208.76.61.100 Sorry, the domain is already pointed to an IP address that does not appear to use DNS servers associated with this server. Please transfer the domain to this servers nameservers or have your administrator add one of its nameservers to /etc/ips.remotedns and make the proper A entries on that remote nameserver. Server: Johnny Domain: thehosthelper.uni.cc DNS: ivan.ns.cloudflare.com, lisa.ns.cloudflare.com I know the error message is reporting me using incorrect NS entries. Problem is my test domain was pointed at another server and I am trying to transfer it here. Since adding an addon domain takes time here (and is not instant), I am trying to cut down on waiting time by adding it while waiting for DNS to transfer. Thanks.

I agree with Piotr, it is possible to cache content that is always changing like on a forum so I don't think it is worth it for Helionot. Setting it up for HelioHost, however, might not be a terrible idea.

I believe their should also be an ntp.conf file in /etc where you can specify this and have it update automatically...

@jje: The problem is not that the username exists but rather that the group exists. To fix this problem, look for the username provided in the "group file" located at /etc/group and then remove it. Command: root@stevie [~]# cat /etc/group | grep jhgca root@stevie [~]# nano /etc/group [CTRL+W] jhgca Remove that line

Webmail needs help... Fantastico needs help...

Softaculous needs help...

Well, that isn't exactly good, is it? Perhaps Johnny was rushed just a little itty bitty bit?

I seem to recall setting this functionality up on here a couple of months ago when it first came out so it should be doable. I'll try and check to make sure it is still doable some time in the next 24 hours if needed.

I believe the set-up of Charlie and Johnny are different, hence why it wasn't mentioned before.

As we know, users are required to log in to cPanel once every 30 days to keep their account active. However, in all the documentation they receive (registration email and registration page) they are told to go to theirdomain/cpanel. This redirects to the ".html" version of cPanel and therefore does not count their logins. I propose that the Apache configuration be modified such that the domain/cpanel redirects to the ".php" version of the page.

404 error...

Sometimes, ISP's can try and cache things to save bandwidth. This is generally bad and if you find this happening to you I suggest you look for a new ISP. This method of caching can usually be detected when you know it is not your browser and the content appears updated when viewing the site through a proxy.