I currently have a few RPM remote repos pointing to different mirror paths.
One of my remote repos "centos-repo" points to:
http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/
In my rpm.repo file I have:
[Artifactory]
name=Artifactory
baseurl=https://$user:$pass#re-artifactory.company.com/artifactory/centos-rpm/
enabled=1
gpgcheck=0
when I do the following in my docker image it works:
dnf install -y openssl
Now if I change my rmp.repo file to point to my virtual repo "rmp" like this:
[Artifactory]
name=Artifactory
baseurl=https://$user:$pass#re-artifactory.company.com/artifactory/rpm/
enabled=1
gpgcheck=0
my openssl download does not work. It gives the following error:
#29 124.4 - Curl error (28): Timeout was reached for https://<user>:<pass>#re-artifactory.company.com/artifactory/rpm/repodata/repomd.xml [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
The path in the error to the repomd file is now incorrect. It is not able to properly point to what I have set in my remote repo.
Not sure what is the Artifactory version you are using, however the issue you describe sounds similar to the public issue - RTFACT-26309.
After looking into the mentioned issue, it seems that it is now resolved, however, the version it will be fixed with is not yet released. The fix should be delivered with one of the 7.37.x versions.
I hope this information helps.
I am trying to install gnocchi-api, gnocchi-metricd and python-gnocchiclient with apt-get. I found that the postinst scripts in /var/lib/dpkg/info have some misconfigured ports due to which I cannot install the packages successfully. I wanted to ask if there is a way to change the post-installation scripts nad then re-install the package.
Thanks.
Ideally this kind of problems would be solved by filing a bug report (possibly with a patch) and letting the maintainer upload a fixed version that you can upgrade to.
If you need an immediate local workaround though, you could do the following:
Either apt download <package> or dpkg-repack <package> if for example this is a local package only, or the archive does not contain the version you are interested in f.ex.
dpkg-deb -R <package_version_arch>.deb bin-dir
sensible-editor bin-dir/DEBIAN/postinst
sensible-editor bin-dir/DEBIAN/control ideally to bump the version to mark this as a local modification, say by appending +local1 or similar.
dpkg-deb -b bin-dir .
dpkg -i <package_local-version_arch>.deb
I tried the following command in Julia to install FixedEffectModels, but I'm getting this error:
julia> Pkg.add("FixedEffectModels")
INFO: Initializing package repository /root/.julia/v0.4
INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
ERROR: failed process: Process(`git clone -q -b metadata-v2 git://github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
in anonymous at ./pkg/dir.jl:52
I'm using a proxy connection, is it related?
On Windows 7, it seemed to me the .gitconfig worked. But are you sure it's in the correct user home directory (C:/Users/Username by default) and that it is really .gitconfig and not .gitconfig.txt (like I managed to do on my first attempt)?
Your home is root??
Look at this discussion could be inspiring.
export https_proxy=... and Pkg.setprotocol!("https") could probably help?
I also propose to upgrade julia. Because you are using Ubuntu, you could add this ppa:
sudo add-apt-repository ppa:staticfloat/juliareleases
sudo apt-get update
and you could have julia 0.5.2 (unfortunately it was not updated after 0.6)
But if you trust packages on github then you could probably download julia 0.6.1 too. :)
Thegit config --global url."https://github.com/".insteadOf git://github.com/ solve momentarily but after a server reboot it didn't worked anymore, the best solution found in this discussion was installing Julia 0.6+ because it can use the environment variables, so the export take effects in Julia.
First off - I know this isn't a specific code problem, so feel free to vote to close the question, but I've spent the better part of half of my day today struggling with this problem and could use some help. I also think this thread can help anybody trying to get sftp protocol working in R, since I'll share what I've done today.
I have been attempting to update RCurl so it supports sftp protocol. In R, my protocols look as such (with version and host as well):
> library(RCurl)
> curlVersion()$protocols
[1] "dict" "file" "ftp" "ftps" "gopher" "http" "https" "imap" "imaps" "ldap" "ldaps" "pop3" "pop3s" "rtsp" "smb" "smbs"
[17] "smtp" "smtps" "telnet" "tftp"
> curlVersion()$version
[1] "7.43.0"
> curlVersion()$host
[1] "x86_64-apple-darwin15.0"
Not great - no sftp option...
I followed this thread - http://andrewberls.com/blog/post/adding-sftp-support-to-curl - to update curl on my machine, and was partially successful in doing so. The success part is reflected in when I run the following in the command line:
curl -V
curl 7.55.1 (x86_64-apple-darwin15.6.0) libcurl/7.55.1 zlib/1.2.5
libssh2/1.8.0
Release-Date: 2017-08-14
Protocols: dict file ftp gopher http imap ldap ldaps pop3 rtsp scp sftp smtp telnet tftp
Features: AsynchDNS IPv6 Largefile libz UnixSockets
This is great, because I've got curl updated. However, when I load RCurl and run curlVersion() in R, it's not updated. I've examined the lib folders of my /usr/ directory and have the following problem. In both my /usr/lib AND /usr/local/lib, there exists libcurl files. Specifically:
libcurl.3.dylib, libcurl.4.dylib, and libcurl.dylib in /usr/lib
libcurl.4.dylib, libcurl.dylib, libcurl.a and libcurl.la in /usr/local/lib
The files in my /usr/local/lib directory are the new files that I'd like used, however here is where my major headache began. I copied the four files from /usr/local/lib into /usr/lib and I BROKE MY COMPUTER. Many of my applications stopped loading, and I had to reinstall my OS X on account of being afraid of messing anything else up. When I reinstalled my OS X, it put my files back into their respective folders (how they look in the bullets above).
If I had to guess, I probably shouldn't have moved the .a or .la files... I'm not sure.
One last thing - when i run $ $PATH in console, I get:
$PATH
-bash: /Users/Home/.rvm/gems/ruby-2.3.3/bin:/Users/Home/.rvm/gems/ruby-2.3.3#global/bin:/Users/Home/.rvm/rubies/ruby-2.3.3/bin:/Users/Home/anaconda2/bin:/usr/local/git/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin:/Users/Home/.rvm/bin: No such file or directory
/usr/local/bin is before /usr/bin. but I don't see anything with /usr/local/lib or /usr/lib - could I add these (/usr/local/lib) to my path to fix this? .libPaths() in R gives me this:
.libPaths()
"/Library/Frameworks/R.framework/Versions/3.4/Resources/library"
...if it helps at all
EDIT - I should note that the root of all problems, ofcourse, is that since 'sftp' is not listed in curlVersion()$protocols in R, that when i run RCurl::getURL(), or RCurl::ftpUpload() (im hoping to use ftpUpload), for both I receive the error:
> RCurl::ftpUpload(what = 'myfile.txt', to = 'sftp://userid:userpw#ip/'myfile.txt')
Error in function (type, msg, asError = TRUE) :
Protocol "sftp" not supported or disabled in libcurl
Thanks!
Phew! Finally got this working in an Ubuntu 14.04 docker container with rstudio-server. I hit every issue! But I had to spend more hours than I care to count finding all this stuff, so trying to put it all in one place for anyone else having this problem Here's what I did...
In the linux terminal:
apt-get install libcurl4-openssl-dev
wget libssh2 and then compile with ordinary
./configure
make
make install
wget curl and then compile
./configure --with-sshlib2=/usr/local
make
make install
If you need curl to work in the terminal with sftp, it still may not at this point. Verify its using the new libcurl.so.4 that you just installed. The curl you just installed will install into /usr/local/bin, so use ldd to verify its not using an old library. Mine was using an old libcurl so I linked the old libcurl to the new libcurl in /usr/local/lib and then recompiled curl.
If you want RCurl to work, copy all of the new libs from /usr/local/lib (libcurl & libssh2) to /lib, then move to the R console.
In Rconsole:
install.packages("RCurl", type = "source")
verify sftp protocol is enabled
libcurlVersion()
RCurl::curlVersion()
These should show you enabled protocols for libcurl and RCurl respectively. Cross your fingers for sftp!
Just in case, I also did these things that probably didn't do much but I did when I was hitting a wall and just kept in place.
upgraded R and R studio-server
removed the R version of curl and RCurl prior to reinstalling RCurl. Also in newer rstudio am not sure the type="source" is needed.
Also as Canovice noted, be careful moving around libcurl and libssh libraries. I broke networking a couple of times, fortunately since it was a docker container I just restarted. I found that moving everything at once worked best,
cp /usr/local/lib/libssh* /lib && cp /usr/local/lib/libcurl* /lib
Should also note I'm a total R novice so there may be cleaner ways to do this than moving libraries all over the place. I tried utilizing .libaths() in rstudio, but gave up in the end.
Installing RCurl from source did the trick for me !
install.packages("RCurl", type="source")
I found the solution here - http://www.omegahat.net/RCurl/FAQ.html - specifically, the following lines.
"I can't use scp or sftp within RCurl but the documentation for curl seems to suggest that it can. So why does RCurl not support it?
RCurl does support it, but the likely problem is that the version of libcurl you have installed does not support it. You can check what protocols your libcurl and hence RCurl supports via the command curlVersion. If scp and sftp are not there, reinstall libcurl but with support using libssh2. You will need to have the libssh2 development libraries and headers installed before installing libcurl. On some OSes, you will need to rebuild RCurl from source."
In general, this is a great summary of my issue from start to finish. If your version of RCurl doesn't support sftp, you need to install (at the command line) libssh2 first, then reinstall libcurl, then rebuild from source for some reason.
In practice i've found it more dangerous to try updating an existing curl and openssl installation, than installing an entirely new version and updating PATH envars where they'll be used
In my case my newer curl and openssl with sftp support where installed into
/usr/local/opt/curl-openssl/bin
/usr/local/opt/openssl/lib/
Consequently I needed to set the following envars
PATH="/usr/local/opt/curl-openssl/bin:${PATH}"
LIBRARY_PATH="/usr/local/opt/openssl/lib/:${LIBRARY_PATH}"
before executing
install.packages("RCurl", type="source")
Using Vagrant ssh on Windows 7, mrt add scss (as an example) displays the following in the console:
vagrant#vagrant:/vagrant/MyMeteorApp$ mrt add scss
scss
tag: https://github.com/fourseven/meteor-scss.git#v0.5.1.1
fs.js:730
return binding.symlink(preprocessSymlinkDestination(destination, type),
^
Error: UNKNOWN, unknown error '/vagrant/MyMeteorApp/packages/scss'
at Object.fs.symlinkSync (fs.js:730:18)
at /usr/local/lib/node_modules/meteorite/lib/dependencies/package.js:129:10
at /usr/local/lib/node_modules/meteorite/lib/sources/git.js:75:15
at ProxyWriter.<anonymous> (/usr/local/lib/node_modules/meteorite/lib.souces/git.js:138:5)
at DirWriter.EventEmitter.emit (events.js:92:17)
at end (/usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:323:12)
at /usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:313:32
at endUtimes (/usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:239:48
at setProps (/usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:296:5)
The same error is displayed when attempting to install any Atmosphere package the first time. The command does update "packages" in smart.json:
"packages": {
"scss": {}
}
Whenever mrt is run again, the console displays smart.json changed.. installing from smart.json and hangs.
I did find the package at /home/vagrant/.meteorite/packages/scss but it is nowhere else.
My environment was set up using the Vagrant Chef provisioning. Node is version 0.10.10. The OS is Ubuntu. I have tried reinstalling meteorite using the -H command. Any help is appreciated, I've been trying to get this to work for two days now.
I think that's the problem. Meteorite 0.6.0 uses symlinks but Windows can't handle it. Try copying the sass folder into packages instead of making them symlinks.
Some packages you will need to copy with cp -rL