Open opoplawski opened 5 years ago
mingwandroid
commented
5 years ago You are meant to deactivate conda to stop it from being used. You should not be adding it to your PATH permanently or globally.
Why do you say we shouldn't provide the binaries? Can you detail why? I don't know a whole lot about them.
opoplawski
commented
5 years ago Right, but a user wants to use anaconda, so they activate their environment. All of a sudden kinit, krenew, etc are broken and they can no longer get or renew kerberos tickets breaking access to network resources.
I'm really scratching my head as to why anaconda is providing a kerberos library at all rather than using the system versions. Kerberos installations are generally very OS specific and highly customized to the institutional environment. It's doubtful that any kerberos build that anaconda provides will actually be workable.
msarahan
commented
5 years ago using the system versions
is something that we really can't depend on for much. We have krb5 as a dependency of:
We'd be open to some kind of CDT-type package, or perhaps to removing the CLI programs, as long as we knew that we weren't breaking people. We need to keep our krb5 package's overall effect similar for continuity, but we could make it a metapackage that ties together the shared libraries in one package (probably necessary for our dependents here) and the CLI in another.
This is a fair amount of work, though. I'd like to understand why you're the first one to report this. These are not new packages. Is there anything unique about the way you are using things?
Maybe the best workaround is for you to provide dummy packages for krb5 that are just empty. Conda could use your packages to satisfy the deps, and the conda krb5 package contents would then not get in your way. Binary compatibility would need to be maintained, though - your system krb5 would need to be binary compatible with the krb5 that we provide. There's no way around that - we can't provide the above listed packages for arbitrary site-specific krb5.
opoplawski
commented
5 years ago I explored the possibility of a dummy package, but that won't work on EL7 due to a soname bump in libcom_err from 1.15 to 1.16.
However, it may be possible that the issue is just some missing build deps. It appears that on Linux (or at least RedHat) you need the keyutils and keyutils-libs-devel packages in order for Kerberos to handle the KEYRING credentials cache type - which I what is leading to the error I'm getting. I would look for messages about:
checking for add_key in -lkeyutil
checking for keyctl_get_persistent in -lkeyutils...in the configure output.
On Mac the default credential cache type appears to be "API", as klist shows:
Credentials cache: API:0C54E75F-63A7-44C6-8246-A14BD57B6452So presumably there may be some kind of missing dependency there. Although I would not rule out that Apple's kerberos is heavily patched.
vgeck
commented
5 years ago Hei,
we have the same issue, our workaround is downgrading krb5 to 1.15.1, then it works!
conda remove krb5 --force -y
conda install krb5==1.15.1 --no-deps -y
Ladas
commented
5 years ago I see the same issue Unknown credential cache type while resolving ccache when running kinit on Fedora 30
I can't install conda install krb5==1.15.1 --no-deps -y because of other deps
The following packages are causing the inconsistency:
- defaults/linux-64::pycurl==7.43.0.2=py37h1ba5d50_0
- defaults/linux-64::curl==7.64.0=hbc83047_2
- defaults/linux-64::anaconda==2019.03=py37_0
- defaults/linux-64::libcurl==7.64.0=h20c2e04_2
failed
PackagesNotFoundError: The following packages are not available from current channels:
- krb5==1.15.1
I've endup doing conda install krb5==1.14.2 -y
SpiralArray
commented
4 years ago This is a huge issue for us as we attempt to move completely from a centralized Python 2 install to a decentralized Python 3 Anaconda environment. We use pyodbc to connect to many MSSQL instances with AD credentials from RHEL 7 systems (thus, using krb5). With krb5 1.16+ unable to recognize the default system cache (KEYRING:persistent), Anaconda 3 is pretty much a no go for us.
wil
commented
4 years ago @SpiralArray when using pyodbc to connect to MSSQL, which odbc driver are you using?
I find that if I use the official Microsoft ODBC driver for Linux it will find the RHEL system libkrb5 and therefore has no problem authenticating with AD credentials (trusted authentication.)
However, you may find that if you're using FreeTDS to connect, that if your FreeTDS comes from a condo package, that it brings in the krb5 condo package and run into this issue. We have the same issue with pymssql which uses FreeTDS, and I have to workaround this issue by building our own FreeTDS conda package.
SpiralArray
commented
4 years ago @wil Thanks for that heads up. I will check and revert back.
SpiralArray
commented
4 years ago @wil - late follow-up, I know (3.5 months!), but I get the same error when using the official MSODBC driver for Linux.
wil
commented
4 years ago @SpiralArray if you run ldd on the MSODBC driver dynamic library, where is libkrb5.so.3 pointing to? Mine is pointed to the system Kerberos which works well.
ldd /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.3.so.1.1
linux-vdso.so.1 => (0x00007ffcbd4f0000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0529108000)
librt.so.1 => /lib64/librt.so.1 (0x00007f0528f00000)
libodbcinst.so.2 => /lib64/libodbcinst.so.2 (0x00007f0528cee000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f052888c000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f05285a3000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f0528356000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f05280e4000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f0527edf000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f0527bd8000)
libm.so.6 => /lib64/libm.so.6 (0x00007f05278d6000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f05276c0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f05274a4000)
libc.so.6 => /lib64/libc.so.6 (0x00007f05270d7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0529714000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f0526ecd000)
libz.so.1 => /lib64/libz.so.1 (0x00007f0526cb7000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f0526a84000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f0526880000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f0526670000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f052646c000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f0526253000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f052602c000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f0525dca000)If it is linked against the conda krb5 package, that's when it doesn't behave correctly. At least that was the issue I found, and I had to try very hard not to pull in the conda krb5 package.
SpiralArray
commented
4 years ago @wil - my ldd output is the same as yours, Now, I ran a strace on a simple pyodbc query script and noticed that the way krb5-1.17.1 for anaconda3 is configured is incorrect for RHEL 7 (well, at least ours), as these settings in /opt/anaconda3/bin/krb5-config show:
DEFCCNAME='FILE:/tmp/krb5cc_%{uid}' DEFKTNAME='FILE:/etc/krb5.keytab' DEFCKTNAME='FILE:/opt/conda/var/krb5/user/%{euid}/client.keytab'
The default credentials cache in our RHEL 7 is KEYRING:persistent:%{uid}. It's possible that with just this one change to DEFCCNAME in configure and a rebuild/reinstall of krb5, things might start working. I think I'll give a rebuild from source a shot. Stay tuned!
will
commented
4 years ago @will - my ldd is the same as yours,
It's probably not the same though since I'm usually using macos, so it's otool -l instead of lld but idk
SpiralArray
commented
4 years ago ahh, that one extra "l" in Wil got me, Thanks, fixed it.
SpiralArray
commented
4 years ago @wil -Bingo! Hope the following will help others:
By downloading 1.17.1 the source code, and running configure with just --prefix=<our anaconda3 dir>, it uses the built-in krb5-config tool pick up on the local system's default settings:
DEFCCNAME='KEYRING:persistent:%{uid}'
DEFCKTNAME='FILE:~/%{uid}.keytab'
DEFKTNAME='FILE:/etc/krb5.keytab'
After a make/make install, I am now able to successfully use pyodbc with Kerberos credentials.
@mingwandroid - even though anaconda is not really meant to be a default global environ for all users of a system, it's popularity among data scientists made it a natural fit for us as a shared platform. Unless I'm missing something, this krb5 issue affects personal-dev and shared production users alike, basically anyone using the conda initialize to setup their environment.
shubhanshu-taiger
commented
3 years ago Hi @SpiralArray thanks for the details in your last post. We are also facing same issue in our RHEL 7, PyODBC, MSSQL environment. But using your above mentioned steps, still issue is not resolved. I followed these steps.
After these steps i can see updated krb5-config file but still issue is not resolved. My krb5-config (under /usr/local/anaconda3/bin/krb5-config) after above steps is still the same mainly DEFCCNAME, DEFKTNAME and DEFCKTNAME variable.
version_string="Kerberos 5 release 1.17.1"
prefix=/usr/local/anaconda3
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
CC_LINK='$(CC) $(PROG_LIBPATH) $(PROG_RPATH_FLAGS) $(CFLAGS) $(LDFLAGS)'
KDB5_DB_LIB=
LDFLAGS=''
RPATH_FLAG='-Wl,--enable-new-dtags -Wl,-rpath -Wl,'
PROG_RPATH_FLAGS='$(RPATH_FLAG)$(PROG_RPATH)'
PTHREAD_CFLAGS='-pthread'
DL_LIB='-ldl'
DEFCCNAME='FILE:/tmp/krb5cc_%{uid}'
DEFKTNAME='FILE:/etc/krb5.keytab'
DEFCKTNAME='FILE:/usr/local/anaconda3/var/krb5/user/%{euid}/client.keytab'Please help with the issue if possible. @opoplawski
minwhoo
commented
2 years ago I was able to rebuild krb5 from source successfully with two additional steps before building:
keyutils.h must be available during build for krb5 to support keyring as ccache.
sudo apt-get install libkeyutils-devDEFCCNAME=KEYRING:persistent:%{uid} ./configure --prefix='/usr/local/anaconda3'After these steps, run make and make install.
darklord1807
commented
5 months ago Hello @minwhoo, did it worked? I am on Mac and getting same issue.
minwhoo
commented
5 months ago Yes, but my OS was ubuntu, not macos. Not sure if the steps for building krb5 from source code is the same for macos as well.
The system kerberos is generally customized to its environment. The anaconda krb5 package thus can break kinit and system kerberos utilities. I've seen this on both RHEL7 and Mac OS X.
I would strongly suggest re-configuring the krb5 package to at least not provide the command line utilities. Though I'm curious as to why it's being provided at all.
Actual Behavior
Expected Behavior
Steps to Reproduce
Activate an anaconda environment with the krb5 package installed
Anaconda or Miniconda version:
krb5 1.16.1 h173b8e3_7
Operating System:
OS X and RHEL 7
conda infoconda list --show-channel-urls