When I check the list of ciphers what RabbitMQ/Erlang supports, I see the following:
[root#node ~]# rabbitmqctl eval 'ssl:cipher_suites().'
[{dhe_rsa,aes_256_cbc,sha256},
{dhe_dss,aes_256_cbc,sha256},
{rsa,aes_256_cbc,sha256},
{dhe_rsa,aes_128_cbc,sha256},
{dhe_dss,aes_128_cbc,sha256},
{rsa,aes_128_cbc,sha256},
{dhe_rsa,aes_256_cbc,sha},
{dhe_dss,aes_256_cbc,sha},
{rsa,aes_256_cbc,sha},
{dhe_rsa,'3des_ede_cbc',sha},
{dhe_dss,'3des_ede_cbc',sha},
{rsa,'3des_ede_cbc',sha},
{dhe_rsa,aes_128_cbc,sha},
{dhe_dss,aes_128_cbc,sha},
{rsa,aes_128_cbc,sha},
{rsa,rc4_128,sha},
{rsa,rc4_128,md5},
{dhe_rsa,des_cbc,sha},
{rsa,des_cbc,sha}]
...done.
However my OpenSSL (1.0.1e-fips) seem to be supporting more than this.
My question is, how can I add more ciphers to RabbitMQ to use? To be more specific, I would like to use GCM ciphers.
If I add one to the configuration file, for example:
{dhe_rsa,aes_128_gcm,sha256}
it simply won't work like it does with the others.
If you have the newest version of erlang, you can check if some older versions supported this cipher, maybe it was deleted in some update.
Related
I have been using Clojure, ClojureScript, lein, shadow-cljs, Emacs, and CIDER to work on a Clojure/ClojureScript dynamic web app project.
Usually, I build the project by executing the command cider-jack-in-cljs in Emacs, choosing shadow-cljs, then shadow for REPL type, and, finally, app for the building option.
It works fine. I can watch changes on the UI on localhost:3005.
Based on this previous question, I would like to understand better which HTTP server I am using.
Doing a git grep, I can find:
Pedros-MacBook-Air:balance pedro$ git grep ":dev-http"
Pedros-MacBook-Air:balance pedro$ git grep ":http"
shadow-cljs.edn: :http-root "public"
shadow-cljs.edn: :http-port 3005
Hence, I suppose I can conclude the HTTP server is not :dev-http, right?
If so, how can I make :dev-http the default?
Just tweaking shadow-cljs.edn to add :dev-http?
Should I remove current :http-root "public" and :http-port 3005?
:http-root and :http-port in the :devtools part of the build config is the old (and deprecated) style of configuring http servers in shadow-cljs. :dev-http is the new notation.
So your config is identical to setting :dev-http {3005 "public"} (and removing the http parts from :devtools). They are functionally equivalent otherwise.
I'm trying to connect to Bloomberg through the FIX protocol (4.4) using QuickFIX/n.
Bloomberg requires to use the TLS 1.2 protocol. I have installed the PFX certificate following the instructions.
My current FIX config file looks as follows:
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=store
FileLogPath=fixlog
StartTime=06:00:00
StartDay=monday
EndTime=22:00:00
EndDay=friday
SocketConnectHost=xxx.xx.xxx.xx
SocketConnectPort=8228
# standard config elements
[SESSION]
BeginString=FIX.4.4
SenderCompID=MY_COMP_ID
TargetCompID=BBG_COMP_ID
HeartBtInt=60
ValidateFieldsOutOfOrder=N
UseDataDictionary=Y
DataDictionary=FIX_BBG.xml
CheckLatency=N
[SSL]
SSLEnable=Y
SSLProtocols=Tls12
SSLValidateCertificates=Y
SSLCheckCertificateRevocation=N
SSLCertificate=C:\Services\FixEngineService\cert\pkcs12\cert.pfx
SSLCertificatePassword=xxxxxxxxxxxx
When I open the session, I immediately get disconnected.
Actually, it's not a network problem as the server is reached.
Bloomberg tells me that they have an "Unknown Protocol" message.
I don't get any log on my side.
Do you see something wrong in my configuration?
Is there someone that successfully set up a quickfix connection with Bloomberg? If yes what could be wrong in my settings from your experience?
You should put the SSL options under the session that it applies to. In your case:
[SESSION]
BeginString=FIX.4.4
SenderCompID=MY_COMP_ID
TargetCompID=BBG_COMP_ID
HeartBtInt=60
ValidateFieldsOutOfOrder=N
UseDataDictionary=Y
DataDictionary=FIX_BBG.xml
CheckLatency=N
SSLEnable=Y
SSLProtocols=Tls12
SSLValidateCertificates=Y
SSLCheckCertificateRevocation=N
SSLCertificate=C:\Services\FixEngineService\cert\pkcs12\cert.pfx
SSLCertificatePassword=xxxxxxxxxxxx
I post the config that worked for me. In case other people struggle with the same configuration issue.
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=store
FileLogPath=fixlog
StartTime=06:00:00
StartDay=monday
EndTime=22:00:00
EndDay=friday
SocketConnectHost=xxxx.xx.xxx.32
SocketConnectPort=8228
# standard config elements
[SESSION]
BeginString=FIX.4.4
SenderCompID=MAP_MY_BETA
TargetCompID=MAP_BLP_BETA
HeartBtInt=60
ValidateFieldsOutOfOrder=N
UseDataDictionary=Y
DataDictionary=FIX_BBG.xml
CheckLatency=N
SSLEnable=Y
SSLProtocols=Tls12
SSLValidateCertificates=N
SSLCheckCertificateRevocation=N
SSLCertificate=C:\Services\FixEngineService\cert\pem\cert.pem
SSLCertificatePassword=xxxxxxxxxx
SSLCACertificate=C:\Services\FixEngineService\cert\pem\CACerts.pem
SSLRequireClientCertificate=Y
Also don't forget to import the pfx certificat for the right user.
Best,
Is there a way to delete GAVs through a REST API in Nexus 3? From various
google searches it appears that this capability existed in Nexus 2, but not in
Nexus 3 yet. Is that true?
I tried the following with my current Nexus installation, which is OSS 3.2.1-01:
I was trying to delete GAV:
groupId = org.mycompany.myproject
artifactId = myartifact
version = 1.0.0
$ curl --request DELETE --user "USERNAME:PASSWORD" --write-out '%{http_code}\n' http://my-server:8081/service/local/repositories/my-repo/content/org.mycompany.myproject/myartifact/1.0.0
This gave me a 405.
I also looked at the release notes for 3.3 through 3.5 and nothing jumped out
that REST API support was added.
I also looked into
https://help.sonatype.com/display/NXRM3/REST+and+Integration+API. I downloaded
the nexus-book-examples and downloaded several of the Javadocs (nexus-core,
nexus-repository, nexus-common, nexus-script, nexus-commands, nexus-selector)
for version 3.2.1-01 and started to look through the code. It was not clear
where to start with a simple program to delete GAVs.
Am I correct that you cannot delete GAVs through the REST API in Nexus 3? Is
there a plan to support this in a future Nexus 3 release? Is there a way to do
what I want to do by creating a Groovy script using the code referenced by the
REST+and+Integration+API link above? Is there some sample code which will help
bootstrap me to using the above code (either 3.2.1-01, or a newer version of
Nexus).
Thanks.
You might take a look at our Beta REST API in Nexus Repository 3. Upgrade to a version greater than 3.3, preferably to 3.5 (just so you are using latest and greatest) and navigate to:
http://nexushostname:nexusport/swagger-ui/
Since the REST API is currently Beta we have yet to publish documentation or fanfare around it while we let people experiment with it and give us feedback.
You should see endpoints for deleting components and assets. You will likely want to use the component delete, so that it will clean up all associated assets.
Let me know your mileage!
According to the documentation, you can delete an ASSET (individual file) or a COMPONENT (a set of files, like jar+md5+sha1+pom.xml representing an artifact) only if you know the assetId or the componentId
https://help.sonatype.com/repomanager3/rest-and-integration-api/components-api
https://help.sonatype.com/repomanager3/rest-and-integration-api/assets-api
So you should issue a separate search call passing the GAV and finding out the componentId, then use the componentId to delete in a second call.
However I see here https://issues.sonatype.org/browse/NEXUS-11266 and here
https://issues.sonatype.org/browse/NEXUS-11881 that people can delete an asset just by specifying the entire path... I have tried with
curl -u admin:admin123 -X "DELETE" -w "%{http_code}" http://localhost:8081/repository/deployments/org/apache/commons/commons-compress/1.18/commons-compress-1.18.jar
and it gives me a HTTP 204 (no content). In my case "deployments" is a hosted repository. I have tried the same command on "central" (aproxy repo) and I get a 405.
But if I try to download the whole component (including pom, sha1 etc) with
curl -u admin:admin123 -X "DELETE" -w "%{http_code}" http://localhost:8081/repository/deployments/org/apache/commons/commons-compress/1.18/
I get a HTTP 404.
I know, it's painful and in Nexus2 it was much easier.
I'd like to install liip/imagine-bundle in my symfony 2 project. But in order to make barcodes, I installed previously MopaBarcodeBundle.
MopaBarcodeBundle requires "avalanche123/imagine-bundle" which requires imagine/imagine: v0.4.1
And
LiipImagineBundle requires imagine/imagine: ~0.5,<0.7
Obviously composer detects the conflict, as he cannot unistall v0.4.1, and that version is not enough for LiipImagine.
I'd like to know how I could bypass this. Create sorts of aliases in composer and keep the two versions on my project ? I'm not a pro in version management, so I guess this is not possible.
Thank you very much for any help.
Ok, after some code inspection i figured out a way around. MopaBarcodeBundle doesn't really requires avalanche123/imagine-bundle, but it uses it in the service declaration. (To make the link with Imagine classes).
So I changed the service.xml file containing the BarcodeService declaration.
<parameter key="imagine.gd.class">Imagine\Gd\Imagine</parameter>
<service id="imagine" alias="imagine.gd" />
<service id="imagine.gd" class="%imagine.gd.class%" />
I guess thoses lines could be factorised, but i chose to keep it as it was done in avalanche123.
Also a constant from avalanche was used in 5th argument, I changed it to :
<argument>%kernel.root_dir%../web</argument>
Finally I removed avalanche, and then install a newer version of imagine/imagine
I am trying to find a tool that will extract the module version information (a part of the module record) fron an Xserver module. For example, in the Xorg logs I can see the following information for the librecord module in my Xorg.0.log file...
[ 39.892] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[ 39.905] (II) Module record: vendor="X.Org Foundation"
[ 39.905] compiled for 1.9.0, module version = 1.13.0
[ 39.905] Module class: X.Org Server Extension
[ 39.905] ABI class: X.Org Server Extension, version 4.0
Is there a tools that would allow me to easily extract the aforementioned information. Sometimes you can use modinfo on the module and that will have version information, but that does not always work. The only consistent way I know of now is to parse the xorg log file. Thanks.
Yes, there is and you can also try to write a small one.
http://gitorious.org/xdriverprobe
The problem is that xdriverprobe won't compile on newer servers since I didn't update it to the newest ABIs. Also, xdriverprobe is only used for video drivers, but it can be adapted to be used on other modules. The main source code file (xdriverprobe.c) has less than 500 lines, so you can easily learn by reading it.
It works in Ubuntu 11.10... ./xdriverprobe -o moduledata gives the information you want.
Look at its source code. It does:
dlopen() the module
find a symbol called modulenameModuleData (if your module is called modulename)
that symbol is a XF86ModuleData* See /usr/include/xorg/xf86Module.h
check its member named vers
Spend a few hours and you'll be able to write a very tiny code that does what you want.
More information: http://www.xfree86.org/current/DESIGN17.html#65 (very old document, but most of what's written there is still true today). If you're not happy with that document, you have to read the Xorg source code.
Happy hacking!