Unable to install packages on macos - r

When I try to install a package in R on macOS I get the following error, both using the GUI menu or install.packages:
Warning: unable to access index for repository https://cran.uni-muenster.de/bin/macosx/el-capitan/contrib/3.5:
cannot open URL 'https://cran.uni-muenster.de/bin/macosx/el-capitan/contrib/3.5/PACKAGES'
There are many Q&A on this site relating to this issue, and none of the answers provided there worked for me.
I tried disabling my firewall, changed all possible settings in the R preferences, checked in my browser whether the packet was online and available (it was), used different options and mirrors, both http and https, in install_packages, to no avail.

If you use Little Snitch, check the rules.
I use Little Snitch in quiet mode and have never defined any rules, and yet Little Snitch had a rule that blocked R from accessing the internet. Maybe Little Snitch installs with a certain set of base rules or creates rules for certain types of software by default. My bit torrent client (qbittorrent) and Cisco's VPN client, which I use to access my university network from home, were both blocked out of the box as well.
I deleted that rule and now packet installation works fine.

Related

SSL-certificates installing packages in R 4.2

I have a problem with a custom local CRAN-mirror (jfrog) under windows on a machine without access to the internet:
in R 4.1.2, I have no problems accessing the mirror via https,
in R 4.2.0, I get errors that the index in PACKAGES can not be accessed via https.
After browsing the web and SO, I saw some more problems alike but none quite the same (see, e.g. here), I got around this issue by adding to my .Rprofile
options(repos = c(CRAN = "internalrepo"),
download.file.method = "curl",
download.file.extra = "-k -L")
to bypass checking SSL-certificates.
This works for me on a computer with access to the local network only, but it seems a bad idea on computers connected to the internet using a custom CRAN mirror.
Also, I would like to understand the cause of the problem. Did something change in the way that R handles SSL-certificates or did we break something in the installation of R 4.2?
sessionInfo() and Sys.getenv() do not show much difference between R 4.1.2 and R 4.2.0 but in R 4.2.0, I saw that there is an additional environment variable
CURL_CA_BUNDLE that points to the R installation directory /etc/curl-ca-bundle.crt
EDIT: 2022-12-14: I believe I tracked down the issue - it's SSL revocation checks that failed when a system only has access to a local network. A new flag was added to 4.2.1+ that can be set to TRUE, allowing SSL revocation checks to be given 'best-effort' attempts to contact, then bypassed. https://bugs.r-project.org/show_bug.cgi?id=18379 But if a machine has internet access, revocation checks will still be allowed to occur, which, I think, is probably the best we can hope for.
ORIGINAL: Just letting you know #clemenskuehn we have the same thing - local mirror working fine in 4.1.2 over HTTPS on some restricted data systems that aren't allowed internet access, then suddenly we update to 4.2.1 on our windows & linux boxes, and the windows machines only (linux works fine) aren't able to use the local mirror anymore,
"warning: unable to access index for repository https://mirror.oursite.com/cran/src/contrib:
cannot open URL 'https://mirror.oursite.com/cran/src/contrib/PACKAGES"
so it's not just you. Did you open a tracker with the R developers? Your workaround works for us so we might put it into production as a stopgap but it definitely be good if we didn't have to allow insecure connections, even though these systems can't get outbound access anyway.

Issue while installing Packages in R

I am facing the below Issue while installing the packages in Rstudio
Warning: unable to access index for repository https://cran.rstudio.com/src/contrib:
cannot open URL 'https://cran.rstudio.com/src/contrib/PACKAGES'
So the problem is with the URL. Note that if you check the PACKAGES URL that it’s failing to access, This problem is often the result of proxies, firewalls, or other traffic filtering software blocking R from accessing remote URL
Try disabling your firewall/anti-virus
Giving R studio access to the firewall etc.
Have a look at the link below. Multiple, possible solutions are provided to the above described problem.
https://support.rstudio.com/hc/en-us/articles/206827897

Unable to access internet within "R" on cmd behind proxy

I have been using R on commandline (BASH). I am unable to access the internet (download any packages). I have tried proxy system wide, and tested it with wget, which works. The "install.packages()" command however does not.
Per some user's advice, I also tried setting the proxy in .Rprofiles file. That didn't help either. Please advice.
I recently ran into the same issue on my work machine. Our Firm uses Cylance as its antivirus software. Cylance was quarantining the file "internet.dll" that R uses to access the Internet. Fortunately, however, it only does so in the 32-bit version of R. For me, there were two solutions:
First, I was able to download packages directly from the 32-bit version of R (outside of RStudio). This works fine. The downloaded packages will run in 64-bit RStudio.
The longer-term solution was to submit an IT service request to release this file from quarantine (that is, to "whitelist a blocked entity"). At my Firm this was promptly done, as there is (obviously) nothing unsafe about this R file.

How to see what web server is running on my mac?

I'm trying to learn how to create a custom WordPress theme. I've been following a tutorial, and I was trying to install DesktopServer onto my MacBook Pro (to create a local environment.)
But I'm not able to install it because it's stating that
"It appears that you have another web server already running. DesktopServer cannot be installed. Check that you do not have Web Sharing turned on from your System Preference -> Sharing control panel or turn off and remove your other web server."
I've checked my Sharing settings, and nothing is enabled (including internet sharing.) So that must mean I have a web server already running. But I don't know what that would be.
Is there a way for me to find out what web server my mac is running?
And after that, is there a way for me to disable that so I could possibly use DesktopServer instead.
I've really good with writing HTML, CSS, Javascript, etc., but I'm pretty new to the server and hosting and stuff. I honestly don't understand everything yet.
I had the same problem, and the solution that worked for me was here:
https://zachgoll.github.io/blog/2018/serverpress-error/
By default, Mac OSX has an Apache server running in the background
which conflicts with Serverpress by default.
To turn it off, run sudo apachectl stop.

Saltstack: network.ip_addrs is not available

I've run into an issue with Saltstack version 2014.7.0, where I cannot get network information from Salt.
If I run:
salt-call network.ip_addrs
I get:
Function network.ip_addrs is not available
This only seems to happen on some of my hosts. It seems to effect the almost all of the functions in salt.modules.network, but everything else works as expected.
I suspect there's something in my environment to blame. I am running salt within a CentOS 7 docker container. I followed these instructions to get Systemd running under Docker, and it seems to be functioning just fine, so I don't think that's the issue, but I wouldn't be surprised if it's related. I'm using Docker as a development environment, but I will be using these formula to orchestrate virtual machines in production.
Has anyone encountered the network module not being loaded properly? Is there something that needs to be available for that module to be accessible?
I have other mechanisms to get the IP address, but none that are as easy to work with in other salt formulas.
It turns out my problem was that I had my own custom module called "network" which was obscuring the upstream network module.
I'm pretty sure this was working at some point in the past, so I'm wondering if there might have been a change to salt in a more recent version that would cause it to conflict at a module level instead of merging methods from different modules of the same name, but I suppose it's possible that it never worked.

Resources