I am running an EKS cluster. And I have a use case which I will explain below.
So, I am trying to create a scalable CTF (Capture the Flag). Now, the problem is - there are a few challenges in which the participants have to write a few files within the pod. Now, obviously, I don't want, another participant to have the remote session when the first user was writing the files within the pod. If that happens, the second user will automatically get the solution.
In order to avoid this problem, we thought of implementing a solution like "session anti-affinity", i.e., if a pod has a session with one user, the ingress should send the request to another pod, but we are not able to understand how to implement the solution.
Please help us out.
If you are just looking for session affinity solution using ingress, you need to enable proxy protocol first. Which will have information of source ip. In ingress you use the information to achieve affinity.
But the problem statement you had mentioned is kind of locking. at given point only one user has to serviced. Not sure session affinity will help in solving the problem.
We're using a slightly modified community mesosphere cluster. This has mesos-dns installed - so we can resolve master.mesos, and x.marathon.mesos, no problem.
The question is which name we should use to access the Cassandra database (whether with cqlsh or with another application)?
I've found the following in the documentation: cassandra-dcos-node.cassandra.dcos.mesos (https://docs.mesosphere.com/services/cassandra/) but what if we change the cluster name (to say, "foo")? Which bit gets modified? I've played around with all combos, but haven't worked it out.
In the case of Cassandra running on DCOS (which the docs refer to) the Cluster name is dcos. The framework name registered with Mesos is cassandra.dcos. The task name for a running Cassandra server is cassandra.dcos.node,
If you were to change the cluster name to "foo", the framework name would now be cassandra.foo and the server task names would now be cassandra.foo.node.
To access your "foo" Cassandra cluster you would use cassandra-foo-node.cassandra.foo.mesos.
Now an explanation of how:
The DNS names that are created by mesos-dns follow a specific schema, all of which can be found in the official documentation[1].
To summarize the documentation here, mesos-dns creates a DNS name with the following format: taskName.frameworkName.mesos.
In the case of Cassandra the task name is cassandra.dcos.node which mesos-dns turns into cassandra-dcos-node since it doesn't all . in task names. The framework name cassandra.dcos is allowed to have . in it so that stays the same. And mesos is the default value for TLD.
When we put it altogether this is cassandra-dcos-node.cassandra.dcos.mesos.
The original intent was to have a name of node.dcos.cassandra.mesos but due to time constraints and a misunderstanding of how mesos-dns worked, this is what we're left with. Hopefully it can be cleaned up in the future.
[1] http://mesosphere.github.io/mesos-dns/docs/naming.html
The default DNS name for the cassandra server provided by cassandra-mesos framework is cassandra.dcos.node. that is prepended according to the mesos-dns spec to the service cassandra and then to the domain dcos.mesos to form cassandra-dcos-node.cassandra.dcos.mesos.
If you are still unclear, the way to confirm the services name is to:
ssh into the server with mesos-dns (I'll assume it is the mesos-master)
follow the dns service: journalctl -u mesos-dns -f
register a cassandra-mesos service
you are looking for an A record entry similar to:
Jul 14 13:43:09 ip-10-0-7-2.us-west-2.compute.internal mesos-dns[1331]: VERY VERBOSE: 2015/07/14 13:43:09 generator.go:364: [A] cassandra-dcos-node.cassandra.dcos.mesos.: 10.0.1.171
Ok, I want to check if I can run some OS or MQSC commands in MQ server remotely. As long as I know, this could be done with SYSTEM.ADMIN.SVRCONN. In order to do that, I add a remote Queue Manager to my WebSphere MQ client. I put Queue Manager name on the server with proper IP, but when I use SYSTEM.ADMIN.SVRCONN as channel name, I have got: Channel name not recognized (AMQ4871) error.
Also, if I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?
Thanks.
Edit1
I am using WebSphere MQ v.7.0
By "I add a remote Queue Manager to my WebSphere MQ client" I meant I added a remote queue manager to MQ Explorer.
Edit2
I want to explain my question more precisely in this edit. I want to connect to a remote Qmanager via MQ Explorer. I know Qmanager name and its IP ofcourse. Also, the remote Qmanager has both SYSTEM.ADMIN.SVRCONN and SYSTEM.AUTO.SVRCONN channel available. When I check CHLAUTH for these channels, I've got:
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
6 : dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN)
MCAUSER( )
As you can see here, I should be able to connect via these two channels and run some commands. But when I choose SYSTEM.ADMIN.SVRCONN as channel name in remote configuration I get : Channel name not recognized (AMQ4871) and when I choose SYSTEM.AUTO.SVRCONN as channel name, I get: You are not authorized to perform this operation (AMQ4036).
Any idea?
when I use SYSTEM.ADMIN.SVRCONN as channel name, I have got: Channel
name not recognized (AMQ4871) error.
Did you define the channel on the remote queue manager?
if I have a channel name like MY.CHANNEL.NAME and it is a
server-connection channel with mqm as its MCAUSER, can I run some
commands (MQSC or OS) through this channel on the server?
Sure. And so can anyone else. You should read up on MQ security and not expose your queue manager to hackers.
I add a remote Queue Manager to my WebSphere MQ client.
I'm not at all sure what this means exactly. MQ Explorer keeps a list of queue manager definitions. MQ Client is just a library for making connections.
If you meant you added a remote queue manager to MQ Explorer, then it makes sense. In addition to defining the connection in Explorer, you will also have to provision the connection at the queue manager. This means defining the SYSTEM.ADMIN.SVRCONN channel or one with a name of your choosing, defining and starting a listener. If you are on a 7.1 or higher queue manager (it's always good to list versions when asking about MQ), then you will also need to create a CHLAUTH rule to allow the connection, and another CHLAUTH rule to allow the connection with administrative privileges. either that or disable CHLAUTH rules altogether, but this is not recommended.
If I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?
Maybe.
Out of the box, MQ denies all client connections. There are CHLAUTH rules to deny administrative connections, and other CHLAUTH rules to deny connections for any SYSTEM.* channel other than SYSTEM.ADMIN.SVRCONN. Since admin connections are denied, non-admin users must have access provisioned using SET AUTHREC or setmqaut commands before they can use SYSTEM.ADMIN.SVRCONN, hence MQ is said to be "secure by default."
When you create MY.CHANNEL.NAME and connect as an admin, and if CHLAUTH is enabled, the connection will be denied. You would have to add a new CHLAUTH rule such as...
SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD)
...in order to allow the admin connection.
(Note: MQ CHLAUTH blocking rules use a blacklist methodology. The default rule blocks *MQADMIN from all channels. The rule I listed above overrides the default rule because the channel name is more specific, and it blocks *NOBODY - which is a list of user IDs that does not include mqm or any other administrative user ID. It's weird, but that's how it works.)
More on this topic at http://t-rob.net/links, and in particular Morag's conference presentation on CHLAUTH rules is a must-read.
20150506 Update
Response to edits #1 & #2 in the original question is as follows:
The first edit says that the QMgr is at v7.0 and the second shows that the QMgr had CHLAUTH records defined. Since CHLAUTH wasn't available until v7.1, these two statements are mutually exclusive - they cannot both be true. When providing the version of the MQ server or client, best to paste in the output of dspmqver. If the question pertains to GSKit, Java code or other components beyond the base code, then dspmqver -a would be even better.
The MQSC output provided in the question updates completely explains the errors.
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
As Morag notes, the SYSTEM.ADMIN.SVRCONN cannot be used because it has not been defined.
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
The auths error happens because any connection to any SYSTEM.* SVRCONN channel that is not expressly overridden is blocked by this rule. The CHLAUTH rule for SYSTEM.ADMIN.SVRCONN takes precedence because it is more explicit, and allows non-admin connections to that channel. The lack of a similar overriding rule for SYSTEM.AUTO.SVRCONN means it is denied by the existing rule for SYSTEM.* channels as listed above.
As noted previously, it is STRONGLY recommended to go to the linked web site and read Morag's conference presentation on MQ v7.1 security and CHLAUTH rules. It explains how the CHLAUTH rules are applied, how the precedence works, and perhaps most importantly, how to verify them with the MATCH(RUNCHECK) parameter.
To do the MQ Security right, you need at least the following:
Define a channel with a name that does not begin with SYSTEM.* and set MCAUSER('*NOBODY').
Define a CHLAUTH rule to allow connections to that channel, mapping the MCAUSER as required.
If you wish to connect to the channel with mqm or admin access, define CHLAUTH rules to authenticate the channel, preferably using TLS and certificates.
There are several things that you do not want to do, for reasons that are explained in Morag's and my presentations. These include...
Using SYSTEM.AUTO.SVRCONN for any legitimate connections.
For that matter, using SYSTEM.* anything (except for SYSTEM.ADMIN.SVRCONN or SYSTEM.BROKER.*) for legitimate connections.
Allowing unauthenticated admin connections.
Disabling CHLAUTH rules.
Disabling OAM.
I want people to learn MQ security, and to learn it really well. However, as a consultant who specializes in it I must tell you that even customers who have hired me to give on-site classes and help with their implementation have trouble getting it locked down. There are two insights to be gleaned from this fact.
First, if you do not enough time to get up to speed on MQ security then the implementation will not be secure. To study the topic to the point of understanding how all the pieces fit together well enough to devise a decent security model requires hands-on training with a QMgr that you can build, hammer at, tear down, build again, etc. takes weeks of dedicated hands-on study, or months or years of casual study. My advice here is to go get MQ Advanced for Developers. It is fully functional, free, and has a superset of the controls you have on the v7.1 or v7.5 QMgr you are working on now.
Second insight is that there is no shortcut to learning MQ (or any other IT) security. If it is approached as though it were simply a matter of configuration, then it is almost guaranteed to not be secure when implemented. If it is approached as learning all the different controls available for authentication, authorization, and policy enforcement, and then learning how they all interact, and if security is approached as a discipline of practice, then it is possible to achieve some meaningful security.
Addressing that second issue will require an investment in education. Read through the presentations and try out the various controls live on a test QMgr that you administer. Understand which errors go to which error logs, which generate event messages and which type of events are generated. Obtain some of the diagnostic tools in the SupportPacs, such as MS0P which is one of my favorites, and get familiar with them. Consider attending the MQ Tech Conference (where you can meet many of the folks responding here on SO) for more in-depth training.
If you (or your employer) are not ready to commit to in-depth skill building or are trying to learn this for an imminent project deadline, then consider hiring deep MQ Security skills on an as-needed basis because reliance on just-in-time on-the-job training for this topic is a recipe for an unsecure network.
I have several active and one passive (no wan-replication element) Hazelcast clusters.
When some item is added to the global WAN-Replicated map I see following message in the log of the passive cluster instance:
Received wan merge but no merge policy defined!
However, as I understanded from the 'hazelcast-fullconfig.xml', there is default merge policy for the map (hz.ADD_NEW_ENTRY). Also, I tried to set it explicit.
So as I understand, wan-replication merge policy and map merge policy are different things.
According to the manual, passive endpoint should not have wan-replication element.
Any ideas how can I configure wan-replication for the passive endpoints? Have I missed something?
In version 2.x, you should define wan-replication-ref (and merge policy) for passive side also.
See:
testWANClusteringActivePassive test in
https://github.com/hazelcast/hazelcast/blob/maintenance-2.x/hazelcast/src/test/java/com/hazelcast/impl/WanReplicationTest.java
I need help connecting Azure database using SymmetricDS 3.5.1. I can't seem to the configuration correct. I get an error saying "Cannot create PoolableConnectionFactory" with the message either "socket closed" (when I don't specify ssl parameter) or "login timeout" (when I specify the ssl parameter). I have specified a timeout amount in the connection string, however, it does not seem to work and defaults to 30 seconds. Is there any documentation on how to connect to an Azure database using SymmetricDS? Anyway, take a look and tell me what I need to change in my engine.properties file? I have the following:
db.url=jdbc:jtds:sqlserver://MyServer.database.windows.net:1433;database=MyDatabase;user=MyUser#MyServer;password=MyPassowrd;encrypt=true;hostNameInCertificate=*.database.windows.net;loginTimeout=300;useCursors=true;bufferMaxMemory=10240;lobBuffer=5242880;ssl=require
db.user=MyUser#MyServer
db.database=MyDatabase
db.password=MyPassword
db.driver=net.sourceforge.jtds.jdbc.Driver
It turns out you have to use the Microsoft JDBC driver. I didn't see any documentation on how to set it up so for the sake of others this is what I did after reading http://www.symmetricds.org/docs/how-to/connect-to-database
Download the Microsoft jdbc driver
Put the sqljdbc4.jar file in the lib folder of your symmetric folder
Change the *.properties file to be the following connection information...
db.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
db.url=jdbc:sqlserver://{your_server_name}.database.windows.net:1433;database={database_name};user={user}#{your_server_name};password={password};encrypt=true;hostNameInCertificate=*.database.windows.net;loginTimeout=300;useCursors=true;bufferMaxMemory=10240;lobBuffer=5242880;