After upgrading from version 3.0.21 to 3.0.22 freeradius does not start on Ubuntu 18.04:
#freeradius -X
FreeRADIUS Version 3.0.22
Copyright (C) 1999-2021 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
Starting - reading configuration files ...
including dictionary file /usr/share/freeradius/dictionary
...
rlm_ldap (ldapName): Bind successful
Instantiating module "expiration" from file /etc/freeradius/mods-enabled/expiration
Instantiating module "reject" from file /etc/freeradius/mods-enabled/always
Instantiating module "fail" from file /etc/freeradius/mods-enabled/always
Instantiating module "ok" from file /etc/freeradius/mods-enabled/always
Instantiating module "handled" from file /etc/freeradius/mods-enabled/always
Instantiating module "invalid" from file /etc/freeradius/mods-enabled/always
Instantiating module "userlock" from file /etc/freeradius/mods-enabled/always
Instantiating module "notfound" from file /etc/freeradius/mods-enabled/always
Instantiating module "noop" from file /etc/freeradius/mods-enabled/always
Instantiating module "updated" from file /etc/freeradius/mods-enabled/always
Instantiating module "eap" from file /etc/freeradius/mods-enabled/eap
Linked to sub-module rlm_eap_md5
rlm_eap (EAP): Failed to link rlm_eap_leap: /usr/lib/freeradius/rlm_eap_leap.so: cannot open shared object file: No such file or directory
/etc/freeradius/mods-enabled/eap[2]: Instantiation failed for module "eap"
It might have to do with a new feature introduced in 3.0.22:
Remove native support for Cisco LEAP. It is insecure, and should not be used. Proxying LEAP is still supported.
You might need to adapt your config or roll back to 3.0.21.
This one also affected me. My solution was to comment out the leap section of the eap config file, all working after that. Probably a good reminder to turn off all unused configurations in production.
Related
Here is the scenario (newbie to spark scala so kindly bear with me)
1) I have module A and a config file under resources folder. Class C in module A reads this config to get information about the file paths
2) i am trying to call Class C (module A) from Module B (after importing the dependencies of Module A in module B)
3) Issue i am facing is Class C (module) code when invoked from Module B , is using the config from Module B instead of its own config in Module A
Note : code works perfectly when i call with in Module A but once i move this code to Module B its using the resources file in Module B instead of Module A resource file.
both the configs have same name.
From the discussion in regard to my original answer, which assumed Lightbend Config (commonly used in the Scala world), it's been discovered that some sort of config.xml is in src/main/resources for the respective modules. These files both end up on the classpath and each module attempts (by an at this point unspecified means) to load the config.xml resource.
The JVM when asked to load resources always loads the first which matches.
The easiest way in a small set of projects to address this collision is to not collide by giving the configs in each project different names.
An alternative which is viable in a larger set of projects is to use Lightbend Config which allows config file inclusion out of the box, as well as the ability to use environment variables to easily override configurations at runtime.
An elaborate strategy for a larger set of projects, depending on how compatible the XML schemas for the various module's config.xmls are (if they're being read using a schema) is to define a custom Maven build process which embeds config.xmls inside one another so that code in module A and module B can share a config.xml: A only cares about the portion of the config which came from A and B only cares about that from B. I'm not particularly familiar with how one would do this in Maven, but I can't think of a reason why it wouldn't be possible.
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL . However, during compilation it cannot found some header files, namely
pg_config_ext.h and pg_config_os.h.
While looking at the directory structure of PostgreSQL, I find that it does not have these header files. How to fix this issue?
These header files are generated from the respective .in files when configure is run.
This will allow conditional compilation depending on the operating system and its configuration.
To compile PostgreSQL, you need what is called a configured source tree in PostgreSQL jargon.
Also note that the build process is somewhat different on Windows, see the documentation for details.
SQLAPI++ has an unusual feature where you set a string to tell it where to find the ODBC shared library. In my case this is libtdsodbc.so, and my application actually links that library at build time, but at runtime this is not enough for SQLAPI++ to work.
My code is:
SAConnection conn;
conn.setOption("ODBC.LIBS") = "libtdsodbc.so";
conn.Connect("SERVER=...", "", "", SA_ODBC_Client);
ODBC.LIBS is documented like this:
Forces SQLAPI++ Library to use specified ODBC manager library.
The above code works if you set LD_LIBRARY_PATH to a directory containing libtdsodbc.so. But if you don't, Connect() fails:
libtdsodbc.so: cannot open shared object file: No such file or directory
DBMS API Library 'libtdsodbc.so' loading fails
This library is a part of DBMS client installation, not SQLAPI++
Make sure DBMS client is installed and
this required library is available for dynamic loading
Linux/Unix:
1) The directories in the user's LD_LIBRARY_PATH environment variable
2) The list of libraries cached in /etc/ld.so.cache
3) /usr/lib, followed by /lib
It works again if you set ODBC.LIBS to a full path rather than just a filename. But how can the application know which path?
My application (outside of SQLAPI++) finds libtdsodbc.so via its RUNPATH which is set at build time. This path is not a system path like /usr/lib. I'd like to have SQLAPI++ use the same library which is loaded in the application at runtime.
One idea is for the application to inspect its own RUNPATH, search for libtdsobc.so, and use that path. But this requires quite a bit of fiddly code to basically reimplement what ld.so already does.
I don't want to bake the path into the executable at build time separately from RUNPATH, because I sometimes edit RUNPATH before deployment (and then I'd need to edit two things).
Ideally I would like to tell SQLAPI++ to just use the library which is already loaded. I can figure this path out by running lsof -p PID | grep libtdsodbc.so but running shell commands from within the executable is not a good solution (and again I would rather not reimplement lsof).
You could either use dl_iterate_phdr (the link also includes a sample code which prints out lib names) or manually parse /proc/self/maps.
I can't recall if this stopped working at some point or has always been this way. When I develop powershell modules I would like to be able to load them explicitly from my local repo directory to make sure everything is working properly. MSDN indicates this should work, however I get the error:
"The specified module .\SomeModule was not loaded because no valid module file was found in any
module directory. FileNotFoundException"
I would expect this is because it can't find the psm1 file in the directory but I can't understand why. I can load the module by referencing the psm1 file directly but this excludes anything being loaded by the manifest. I can also copy the module to one of the standard module paths and it will load correctly. This is what I've been doing as a work around but I'd love to get this figured out. TIA
**Update: Ran process monitor while running the import command. Interesting results. Seems like it may just be a powershell bug.
You can load the module by referencing the module manifest file (.psd1) directly, which will then ensure any dependencies are loaded.
This seems so trivial, yet I can't get it to work..
I have an msi.dll wrapper (named Interop.WindowsInstaller.dll) which I need to sign. The way to do it is by signing it upon import (this specific case is even documented in MSDN: http://msdn.microsoft.com/en-us/library/zec56a0w.aspx).
BUT - no matter how I do it (w/ or w/o a keyfile, w/ or w/o adding "/delaysign"), the generated assemly's size is always 36,864 bytes and when viewing the DLL's properties there is no "Digital Signatures" tab (needless to say - the DLL is NOT signed).
What am I missing here?? (... HELP!...)
[Note: Eventually I got a hint from Karel Zikmund on this thread, which helped me solve the mystery. I'll paste my reply here - for the greater good].
So, I used the following line to sign-upon-import the assembly:
tlbimp C:\WINDOWS\system32\msi.dll /out:Interop.WindowsInstaller.dll /keyfile:MyKey.snk
I then copied the file to the appropriate location and built the project, but each time the build failed on the following error: Assembly generation failed -- Referenced assembly 'Interop.WindowsInstaller' does not have a strong name.
I thought the problem was with the tlbimp line, but after reading Karel Zikmund's reply and verifying that the DLL is strong-named (using sn -vf Interop.WindowsInstaller) I found out the problem.
Adding a reference to the "Microsoft Windows Installer Object Library" COM object actually planted a code block into the .csproj file.
I didn't realize it, but this block caused the DLL file to be regenerated from scratch upon each time the project was built. The generated file, of course, was not strong-named anymore.
The way I resolved it was to remove the reference to "Microsoft Windows Installer Object Library" from the project, and add a direct file reference to the imported (and already signed) Interop.WindowsInstaller.dll file.