ercpe's questions

The customer wants to use a COMODO signed TLS certificate for LDAPS on a Windows Server 2012 R2 domain contoller.

The certificate was already purchased but the CSR wasn't created on the domain controller (as per https://support.microsoft.com/en-us/kb/321051).

The certificate fullfills the requirements to be used for ADDS:

• The common name is the DC's FQDN
• The certificate can be used for client and server authentication
• The certificate has several SAN entries for alternative DNS names of the domain controller

I've now imported the certificate, the private key and all intermediate certificates into both, the local computer certificate store and the NTDS\Personal certificate store.

However, after importing the certificate using the Certificate MMC Snap-in, the certificate isn't used for LDAPS in ADDS:

Schannel, 36869: The SSL server credential's certificate does not have a private key information property attached to it. This most often occurs when a certificate is backed up incorrectly and then later restored. This message can also indicate a certificate enrollment failure.

I can see that the domain controller tries to use this certificate because the message changes if the certificate is removed:

No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server. Applications that manage their own credentials, such as the internet information server, are not affected by this.

Is there any way to add this certificate so that schannel can use it (i have the private key, the csr, the certificate and all intermediate certificates)?

One of our application uses Elasticsearch (1.4.4) as an in-memory cache. The application is a Java webapp deployed on Tomcat 7 with Oracle 1.7. The elasticsearch instance is a one-node setup deployed on the same server.

Since elasticsearch 1.3.3 we're expiriencing around 40 MBit/s in and out on the loopback interface between the application and the Elasticsearch node with an idle application.

This isn't that much but causes a noticable load for an otherwise flatlining system. I don't have a production system with this application at hand so i can't really say how it evolves in prod.

Grabbing the traffic via tcpdump and analyzing it in Wireshark shows that the Elasticsearch-Client in the application continously ask the Node for cluster/node/info which yields in a 10k answer every time.

Maybe totally unrelated, but enabling the server and client logging gives us:

Elasticsearch Server log:

[2015-05-12 14:45:01,600][INFO ][node                     ] [Illyana Rasputin] initializing ...
[2015-05-12 14:45:01,608][INFO ][plugins                  ] [Illyana Rasputin] loaded [], sites []
[2015-05-12 14:45:06,666][INFO ][node                     ] [Illyana Rasputin] initialized
[2015-05-12 14:45:06,667][INFO ][node                     ] [Illyana Rasputin] starting ...
[2015-05-12 14:45:06,828][INFO ][transport                ] [Illyana Rasputin] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/10.24.1.128:9300]}
[2015-05-12 14:45:06,851][INFO ][discovery                ] [Illyana Rasputin] bkbo_index/TITPDFdtR6SXX5EeOXaidg
[2015-05-12 14:45:09,892][INFO ][cluster.service          ] [Illyana Rasputin] new_master [Illyana Rasputin][TITPDFdtR6SXX5EeOXaidg][dev06][inet[/10.24.1.128:9300]], reason: zen-disco-join (elected_as_master)
[2015-05-12 14:45:09,943][INFO ][http                     ] [Illyana Rasputin] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/10.24.1.128:9200]}
[2015-05-12 14:45:09,944][INFO ][node                     ] [Illyana Rasputin] started
[2015-05-12 14:45:11,283][INFO ][gateway                  ] [Illyana Rasputin] recovered [2] indices into cluster_state

Elasticsearch client:

2015-05-12 14:46:40,683  INFO  [localhost-startStop-1] PluginsService:<init>:151 [Antiphon the Overseer] loaded [], sites []
2015-05-12 14:46:41,548  DEBUG [localhost-startStop-1] TransportClientNodesService:<init>:110 [Antiphon the Overseer] node_sampler_interval[5ms]
2015-05-12 14:46:41,594  DEBUG [localhost-startStop-1] TransportClientNodesService:addTransportAddresses:167 [Antiphon the Overseer] adding address [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,625  DEBUG [localhost-startStop-1] NettyTransport:connectToNode:751 [Antiphon the Overseer] connected to node [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,655  INFO  [localhost-startStop-1] TransportClientNodesService$SimpleNodeSampler:doSample:371 [Antiphon the Overseer] failed to get node info for [#transport#-1][dev06][inet[localhost/127.0.0.1:9300]], disconnecting...
org.elasticsearch.transport.ReceiveTimeoutTransportException: [][inet[localhost/127.0.0.1:9300]][cluster:monitor/nodes/info] request_id [0] timed out after [6ms]
    at org.elasticsearch.transport.TransportService$TimeoutHandler.run(TransportService.java:366)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
2015-05-12 14:46:41,658  DEBUG [localhost-startStop-1] NettyTransport:disconnectFromNode:882 [Antiphon the Overseer] disconnecting from [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]] due to explicit disconnect call
2015-05-12 14:46:41,661  DEBUG [elasticsearch[Antiphon the Overseer][generic][T#1]] NettyTransport:connectToNode:751 [Antiphon the Overseer] connected to node [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,669  INFO  [elasticsearch[Antiphon the Overseer][generic][T#1]] TransportClientNodesService$SimpleNodeSampler:doSample:371 [Antiphon the Overseer] failed to get node info for [#transport#-1][dev06][inet[localhost/127.0.0.1:9300]], disconnecting...
org.elasticsearch.transport.ReceiveTimeoutTransportException: [][inet[localhost/127.0.0.1:9300]][cluster:monitor/nodes/info] request_id [1] timed out after [5ms]
    at org.elasticsearch.transport.TransportService$TimeoutHandler.run(TransportService.java:366)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
2015-05-12 14:46:41,670  DEBUG [elasticsearch[Antiphon the Overseer][generic][T#1]] NettyTransport:disconnectFromNode:882 [Antiphon the Overseer] disconnecting from [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]] due to explicit disconnect call
2015-05-12 14:46:41,676  DEBUG [elasticsearch[Antiphon the Overseer][generic][T#1]] NettyTransport:connectToNode:751 [Antiphon the Overseer] connected to node [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,677  WARN  [elasticsearch[Antiphon the Overseer][transport_client_worker][T#2]{New I/O worker #2}] TransportService$Adapter:remove:280 [Antiphon the Overseer] Received response for a request that has timed out, sent [14ms] ago, timed out [9ms] ago, action [cluster:monitor/nodes/info], node [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]], id [1]
2015-05-12 14:46:41,682  INFO  [localhost-startStop-1] PluginsService:<init>:151 [Ricochet] loaded [], sites []
2015-05-12 14:46:41,722  DEBUG [localhost-startStop-1] TransportClientNodesService:<init>:110 [Ricochet] node_sampler_interval[5ms]
2015-05-12 14:46:41,733  DEBUG [localhost-startStop-1] TransportClientNodesService:addTransportAddresses:167 [Ricochet] adding address [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,734  DEBUG [localhost-startStop-1] NettyTransport:connectToNode:751 [Ricochet] connected to node [[#transport#-1][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,759  DEBUG [elasticsearch[Antiphon the Overseer][generic][T#1]] NettyTransport:connectToNode:751 [Antiphon the Overseer] connected to node [[Illyana Rasputin][TITPDFdtR6SXX5EeOXaidg][dev06][inet[localhost/127.0.0.1:9300]]]
2015-05-12 14:46:41,760  DEBUG [localhost-startStop-1] NettyTransport:connectToNode:751 [Ricochet] connected to node [[Illyana Rasputin][TITPDFdtR6SXX5EeOXaidg][dev06][inet[localhost/127.0.0.1:9300]]]

Yes, this application has two client connections which should be OK (according to the devs). These disconnect/reconnect cycles happen about every minute or so.

Any clues whats going on here? I already disabled multicasting via discovery.zen.ping.multicast.enabled: false.

we have recently set up a new development infrastructure and process for one of our clients. This involves the strict use of subversion as a central source code repository. The svn repositories contains a seperate branch for code on the live system (/branches/live/). The repositories are use for PHP content (mainly Wordpress Blogs), but in future they may hold other asp code as well. Bonus points for a solutions which more or less in the same way with ASP code on Windows Server 2008 R2.

We have two servers: one staging system and one live system. The staging system is updated regularly with the code of the trunk. The live system is update manually. Each webroot on the servers are working copy of either the trunk (staging system) or the live branch (live system).

The current workflow is:

Developing on the dev's box -> commit into the trunk -> auto-deploy on staging system -> testing on the staging system -> merging into /branches/live/ -> manual deployment on live system.

This works for one-way changes very well, however we have some troubles on every wordpress (or plugin) update: The WP update process removes the directories and unpack the archive of the new version. This removes the svn admin area as well, which produces a lot of errors. We could switch to SVN 1.7 with a single, global admin area, but this would only solve on part of the problem.

Finally, we have done the update via the WP Gui, restored the svn admin area, added/removed the files and committed the changes to the trunk. After testing, we had to do basically the same thing on the live server (except the commit, we just reverted the changes and merged the new files from the staging system to the live system).

I'm currently thinking of the following:

• The htdocs of each website is a svn export
• Each website has a svn working copy beside the htdocs directory
• a script which "replays" the changes in the wc from htdocs after an update in WP (rsync'ing the changed files to the working copy, rsync'ing new files and svn add them and finally svn delete the deleted files). The script would have to exclude some files (like wp-config.php, uploads/temp directories, etc.).

Are there better ways to do this? Unfortunaly, a complete CI server is out of scope due to time and budget limitations.

Every few weeks, i receive the message The table 'ttrss_users' is full from an installation of http://tt-rss.org/redmine/ (a RSS reader application written in PHP).

It's always the users table (InnoDB), which has the following layout:

id              int(11)
login           varchar(120)
pwd_hash        varchar(250)
last_login      datetime
access_level    int(11)
theme_id        int(11)
email           varchar(250)
full_name       varchar(250)
email_digest    tinyint(1)
last_digest_sent datetime
created         datetime
twitter_oauth   longtext

The query causing the error is: UPDATE ttrss_users SET last_login = NOW() WHERE id = x and affects only this table (no other table or database on this server).

The only solution i found is to restart the server. Changing MAX_ROWS and AVG_ROW_LENGTH via ALTER TABLE seems to affect MyISAM tables only.

Any ideas?

We are running several virtual machines using KVM with libvirtd with a routed network (the host systems routes an extra subnet for the virtual machines). Host and Guest OS is Gentoo (host on amd64, guests on x86). The VMs are multi-homed with an internal and external network.

A few weeks ago i started to notice sprodic connection issues to our mailserver: The connection timed out. After a few minutes, the connection worked again. During the outage, the internal network is OK, but no traffic goes through the external network (neither in, nor out).

A tracepath shows as the last hop the host. After it, only stars until the maximum hops (again, in and out).

However, if i run a mtr or something similiar from an external host, the connection always succeeds (but only from this host). Because of this, a suspect an arp issues or something like this. I tried to change the ageing time on the bridge, but without success.

Another interesting thing: Pinging another host on the internet from the virtual machine sometimes shows an icmp redirect warning with the IP of the ISP's gateway.

Until now, i have seen this problem only on this single virtual machine, but the setup is not so different from the others. Any ideas?

Edit: Here is the network layout: