yum/dnf Imunify360 and easyapache4 updates failing
Anybody else having problems with this today? Can't do any updates with yum/dnf, tried cleaning the cache and runing makecache, but makecache is failing to update Imunify360 with Curl error (28). Can't make tickets with cpanel anymore, even though I have a license, but my license is from the hosting company and cpanel doesn't allow me to do tickets directly (BS).
-
Just noticed that Easyapache4 had an update yesterday. Maybe that had something to do with it?
Also can't access nginx manager either. Noticed that easyapache4 updated ea-nginx-headers-more. Looks like everything associated with easyapache4 update seems to be broken...
0 -
okay, It appears /usr/bin/python3.6 /usr/local/cpanel/bin/packman_get_list_json was blocking yum. rebooted server and was able to 'yum makecache' before that process started, but it failed to download imunify360 and kernelcare Failed to download metadata for repo 'imunify360-rollout-4': Cannot download repomd.xml:
still cannot access easyapache4 or nginx manager. Still cannot do updates.
0 -
Here is the error for kernelcare too:
- Curl error (28): Timeout was reached for https://repo.cloudlinux.com/kernelcare/8/x86_64/repodata/repomd.xml [Connection timed out after 30000 milliseconds]
0 -
Hey there! This sounds like the CloudLinux mirrors just aren't working well right now, which seems to happen from time to time. Since everything else on the system is working normally I would just try again in a bit and see if that mirror responds. You can also try the classic combo of these commands to see if that refreshes your cache list and you get a different mirror:
yum clean all
yum makecache
yum update0 -
Thanks for the reply. The main problem is that I cannot access nginx manager interface. Also cannot access easyapache4 interface. From what I understand ea-nginx and easyapache4 are updated through the ea4 repo which is working fine. I was able to verify everything else was updated by running:
yum update --disablerepo=imunify360 --disablerepo=imunify360-rollout-1 --disablerepo=imunify360-rollout-2 --disablerepo=imunify360-rollout-3 --disablerepo=imunify360-rollout-4 --disablerepo=imunify360-rollout-5 --disablerepo=imunify360-rollout-6 --disablerepo=imunify360-rollout-7 --disablerepo=imunify360-rollout-8 --disablerepo=kernelcare
Do you happen to have a test environment with ea-nginx installed where you could verify if it's working?
Thanks,
0 -
My personal server uses Nginx and I'm not seeing any issues with that now.
If you use Imunify or CloudLinux your EasyApache packages will actually be coming from the CloudLinux repositories as Imunify uses hardened PHP and most people with CloudLinux installed use the PHP Selector tool.
0 -
The weird thing is that I'm not using cloudlinux and not using imunify360. I do have imunify-av but it's the free version.
Also noticed php-fpm is not working either. Something weird going on here. I verified ea- packages are using @EA4-c8 repo....
I really wish they would bring back tickets for people on hosted accounts.
0 -
It does sound like there may be more happening with the system than just the RPMs. You can always create a ticket with your hosting provider and then they would escalate the issue to us if they aren't able to resolve it.
0 -
yeah, that's just more time because I have to wait for them, then there is the middle man. Much rather go directly to you guys.
0 -
Well maybe I spoke too soon. Not sure why, but it looks like I have a bunch of packages coming from the imunify360 repo even though I'm not using imunify360. Maybe I just need to wait and see if imunify360 repo comes back online.
One thing I noticed is that my server is unable to update imunify360 repo, but from my office I can access the repo just fine. Any chance you could check whether any of your servers are able to access imunify360 repos?
Thanks
0 -
found this in csf (the ip address of download.imunify360.com)
IPSET: Set:bl_GREENSNOW Match:37.27.120.227 Setting:GREENSNOW file:/etc/csf/csf.blocklists
0 -
problem solved. Removed csf.block.GREENSNOW and update worked. All good now. Thanks for your help!
0 -
So the local firewall was blocking an IP that it shouldn't have been?
0 -
yup, apparently my CSF is using GREENSNOW blocklist which added the ip address for imunify360 to it's blocklist at some point in the past 24 hours. it must have been removed sometime this morning but CSF was configured to only update the blocklist every 24 hours. I was able to remove the blocklist then restart csf which downloaded the updated blocklist and the IP was no longer there.
# GreenSnow Hack List
# Details: https://greensnow.co
GREENSNOW|86400|0|https://blocklist.greensnow.co/greensnow.txt0 -
Well it seems this isn't over yet. The other day I added a temporary allow for imunify360 ip in csf, but now the ip address is back in greensnow blocklist with the last update... Can anybody else using csf and greensnow confirm 37.27.120.227 is in your blocklist?
Not sure what's going on here but the only solution I've found is to whitelist that IP or disable greensnow blocklist. The problem I have with that is that if there is something fishy going on over at imunify, maybe it's not a good idea to allow that IP.
Just poking around the net and found that download.imunify360.com (37.27.120.227) is also on BARRACUDA.
The main problem with this is that EasyApache4 quits working every time this happens. Again, I know csf isn't a part of cpanel, but simply having the ip for imunify360 on a blocklist shouldn't cause updates to fail completely and it definitely shouldn't crash any software on the server. why the ip address for download.imunify360.com would cause easyapache4 to fail unless easyapache4 is shutdown for the update process or something like? I don't know.
Honestly surprised nobody else is seeing this.
0 -
I'm not seeing that IP listed on my personal system:
[root@host /]# grep -Ri greensnow /etc/csf/
/etc/csf/csf.blocklists:# GreenSnow Hack List
/etc/csf/csf.blocklists:# Details: https://greensnow.co
/etc/csf/csf.blocklists:#GREENSNOW|86400|0|https://blocklist.greensnow.co/greensnow.txt
/etc/csf/changelog.txt: Modified csf.blocklists for GREENSNOW to use https on existing and new
/etc/csf/changelog.txt: Added the Greensnow blocklist to csf.blocklists for new installs
/etc/csf/csf.blocklists.new:# GreenSnow Hack List
/etc/csf/csf.blocklists.new:# Details: https://greensnow.co
/etc/csf/csf.blocklists.new:#GREENSNOW|86400|0|https://blocklist.greensnow.co/greensnow.txt
[root@host /]# grep -Ri 37.27.120.227 /etc/csf/
[root@host /]#0 -
That makes sense, it wouldn't show up using grep because the blocklist txt file is actually on a remote server. The blocklist is located here:
GREENSNOW|86400|0|https://blocklist.greensnow.co/greensnow.txt
If you go to that website the ip address was listed in that txt file last night when I made the post, but this morning it's gone again.
The easiest way for me to see if the ip is listed is by going to WHM >> ConfigServer Security & Firewall and using the "Search for IP" Feature. If your system did an update around midnight eastern last night and your blocklist settings in csf are configured for 24 hours, then you should see that ip address when you do a "Search for IP"....
0 -
I do see that IP included in the csf.allow configuration, yes, but this isn't causing an issue with updates on my machine. This may be worth contacting CSF directly at https://configserver.com/technical-support/ to see if they have any ideas on why that would cause an issue.
0 -
Well that makes perfect sense why you're not experiencing the issue. If you have that IP already in csf.allow then it must have been set manually at some point, and it's overriding the blocklist.
I'm confident this really isn't a csf problem. This is a cpanel issue. Cpanel built in functions (easyapache4) should continue to work even if that ip address is blocked.
My guess is that the upcp script is going into some kind of loop when it is unable to access the imunify360 repo. The failure to update is somehow locking easyapache.
You should be able to verify this by removing 37.27.120.227 from your csf.allow and adding it to your blocklist and wait for a few minutes until your upcp cron job runs. Once the cron runs my guess is that you'll see what i'm talking about.
0 -
This is a test machine so there were no manual changes to the configuration, but I figured out the root cause of this issue.
This IP does need to be whitelisted on the server because it's part of the CloudLinux network. It was only showing up when I searched manually in the WHM >> ConfigServer page because it's actually in an include file at /var/imunify360/files/whitelist/v2/imunify360.txt which is referenced inside /etc/csf/csf.allow:
# rollout.cloudlinux.com
2a01:4f9:3070:3847::2
37.27.120.227If that IP address is blocked, the updates will fail, but on a standard server this should be allowed in CSF as it was on my test machine.
0 -
gotcha. so on my system that file doesn't exist and it's also not included in /etc/csf/csf.allow. My server is pretty much standard install. I mean, I've tweaked a few things from cpanel settings, but nothing really outside of cpanel has been done to this server.
okay so that is making more sense now. maybe that include file is added when you use cloudlinux, but since i'm not using CloudLinux and only using the free imunify AV that comes with basic cpanel/whm, apparently that imunify360.txt whitelist is not added.
Maybe it would be a good idea for cpanel to add the imunify360 download repo ip (37.27.120.227) to a whitelist somewhere else by default?
Any chance you have access to a regular (non cloudlinux) install to verify this?
0 -
Interesting...let me poke this a bit more and I'll find out!
1 -
I did confirm that a standard installation with just ImunifyAV does not have that file in place at all on the system.
I then installed CSF on this fresh system, and I don't see that allowed there either, so Imunify360 must add that as part of the installation.
I can't say how that IP ended up blocked on your system, but as long as that is blocked there would be issues with any server updates or installs through EasyApache.
0 -
Thanks for the confirmation. I can verify that the greensnow blocklist 100% is adding that ip to the blocklist and then removing it. it's happened twice now that I know of.
Anyway, thanks again!
0 -
Sure thing!
0 -
Just for reference, I manually added 37.27.120.227 to the csf blocklist, then added the following line to /etc/csf/csf.allow
tcp|out|d=443|d=37.27.120.227 # Allow imunify360 updates
Verified upcp was able to complete with these settings. So if anyone else runs into this problem simply add the above line to /etc/csf/csf.allow and you should be good to go.
0
Please sign in to leave a comment.
Comments
26 comments