When upgrading to TeamCity 2023.05 (using the Docker image), I received the error "Can't take exclusive lock when db lock is not held" and the detailed instruction:

<pre>java.lang.IllegalStateException: Can't take an exclusive lock when db lock is not held
    at jetbrains.buildServer.serverSide.db.Heartbeat.tryGetExclusiveLock(Heartbeat.java:726)
    at jetbrains.buildServer.serverSide.db.TeamCityDatabaseManager.tryGetExclusiveLock(TeamCityDatabaseManager.java:857)
    at jetbrains.buildServer.maintenance.StartupProcessor.lockDatabaseExclusively(StartupProcessor.java:860)
    at jetbrains.buildServer.maintenance.StartupProcessor.doUpgradeRequired(StartupProcessor.java:773)
    at jetbrains.buildServer.maintenance.StartupProcessor.checkUpgradeRequired(StartupProcessor.java:826)
    at jetbrains.buildServer.maintenance.StartupProcessor.doDatabaseChecking(StartupProcessor.java:1377)
    at jetbrains.buildServer.maintenance.StartupProcessor.access$1000(StartupProcessor.java:1410)
    at jetbrains.buildServer.maintenance.StartupProcessor$3.call(StartupProcessor.java:12)
    at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:91)
    at jetbrains.buildServer.maintenance.StartupProcessor.processConcreteStage(StartupProcessor.java:779)
    at jetbrains.buildServer.maintenance.StartupProcessor.processConcreteStageSafe(StartupProcessor.java:1165)
    at jetbrains.buildServer.maintenance.StartupProcessor.processTeamCityLifecycle(StartupProcessor.java:1100)
    at jetbrains.buildServer.maintenance.StartupProcessor.access$000(StartupProcessor.java:1120)
    at jetbrains.buildServer.maintenance.StartupProcessor$1.run(StartupProcessor.java:3)
    at java.base/java.lang.Thread.run(Thread.java:833)
</pre>

I spent a lot of time trying to get to the bottom of this, as I initially thought it was something wrong with the actual database, but could not find any locks.

It appears as both debian:stable-slim and debian:stable are both currently broken (for updates):

> $ docker run -ti --rm  debian:stable-slim
Unable to find image 'debian:stable-slim' locally
stable-slim: Pulling from library/debian
fc491617b0f1: Pull complete
Digest: sha256:a85c2c0e634946e92a6f4a9a4f6ce5f19ce7c11885bc198f04ab3ae8dacbaffa
Status: Downloaded newer image for debian:stable-slim
root@e610973ac2f8:/# apt update
Ign:1 http://security.debian.org/debian-security stable/updates InRelease
Err:2 http://security.debian.org/debian-security stable/updates Release
  404  Not Found [IP: 151.101.130.132 80]
Get:3 http://deb.debian.org/debian stable InRelease [113 kB]
Get:4 http://deb.debian.org/debian stable-updates InRelease [36.8 kB]
Get:5 http://deb.debian.org/debian stable/main amd64 Packages [8178 kB]
Reading package lists... Done
E: The repository 'http://security.debian.org/debian-security stable/updates Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Anyone else experienced this or found a workaround?

I recently replaced my pfSense installation with OPNsense and have been struggling a bit with the Unbound installation.

In short, it's IPv6 enabled and everything works well (both IPv6 and IPv4) in general. However, it seems to struggle with DNS look-ups for A Records over IPv6.

Here's an example:

> $ dig +short -6 switch0.my.tld @[redacted]::1
> $ dig +short -6 ipv6.google.com @[redacted[::1
ipv6.l.google.com.

As you can see, the DNS lookup for ipv6.google.com works fine, but not for my domain.

Now, if I do the same query towards the same server but over IPv4, it works fine:

> $ dig +short switch0.my.tld @192.168.200.1
192.168.200.2

I'm not sure if I'm missing anything basic here, but I don't understand why Unbound is not returning the A record over IPv6, but it works over IPv6.

Other IPv4 queries works just fine:

> dig +short -6 google.com @[redacted]::1
172.217.21.142

I'm trying to get Let's Encrypt inside the official Docker Wordpress container.

Setup the environment

$ cat docker-compose.yml
wordpress:
  hostname: some.fqdn.com
  image: wordpress
  links:
    - db:mysql
  ports:
    - 80:80
    - 443:443

db:
  image: mariadb
  environment:
    MYSQL_ROOT_PASSWORD: example

$ docker-compose -f docker-compose.yml up -d
$ docker exec -ti root_wordpress_1 bash

Install Let's Encrypt

$ apt-get update && apt-get install -y git-core
[...]
$ cd /usr/local
$ git clone https://github.com/letsencrypt/letsencrypt
[...] 
$ cd letsencrypt/
$ ./letsencrypt-auto --apache
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --apache
An unexpected error occurred:
PythonDialogBug
Please see the logfiles in /var/log/letsencrypt for more details.

More logs

$ cat /var/log/letsencrypt/letsencrypt.log
2016-03-04 15:28:41,551:DEBUG:letsencrypt.cli:Root logging level set at 30
2016-03-04 15:28:41,553:INFO:letsencrypt.cli:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-03-04 15:28:41,554:DEBUG:letsencrypt.cli:letsencrypt version: 0.4.2
2016-03-04 15:28:41,554:DEBUG:letsencrypt.cli:Arguments: ['--apache']
2016-03-04 15:28:41,555:DEBUG:letsencrypt.cli:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-03-04 15:28:41,559:DEBUG:letsencrypt.cli:Requested authenticator apache and installer apache
2016-03-04 15:28:42,166:DEBUG:letsencrypt.display.ops:Single candidate plugin: * apache
Description: Apache Web Server - Alpha
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = letsencrypt_apache.configurator:ApacheConfigurator
Initialized: <letsencrypt_apache.configurator.ApacheConfigurator object at 0x7fd05eb85310>
Prep: True
2016-03-04 15:28:42,168:DEBUG:letsencrypt.cli:Selected authenticator <letsencrypt_apache.configurator.ApacheConfigurator object at 0x7fd05eb85310> and installer <letsencrypt_apache.configurator.ApacheConfigurator object at 0x7fd05eb85310>
2016-03-04 15:28:42,178:DEBUG:letsencrypt.cli:Exiting abnormally:
Traceback (most recent call last):
  File "/root/.local/share/letsencrypt/bin/letsencrypt", line 11, in <module>
    sys.exit(main())
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/cli.py", line 1993, in main
    return config.func(config, plugins)
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/cli.py", line 658, in run
    domains = _find_domains(config, installer)
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/cli.py", line 133, in _find_domains
    domains = display_ops.choose_names(installer)
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/display/ops.py", line 217, in choose_names
    default=True)
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/display/util.py", line 156, in yesno
    yes_label=yes_label, no_label=no_label)
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/dialog.py", line 3749, in yesno
    kwargs)
  File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/dialog.py", line 1765, in _widget_with_no_output
    widget_name, output))
PythonDialogBug

Anyone got any clues here?

I want to build an image on top of the official Wordpress image that automatically adds Let's Encrypt.

On a semi-regular basis, I've seen GCE instances freezing with the following error message (from the serial console):

g[1375589.784755] BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
g[1375589.786206] IP: [<ffffffff810a67d9>] check_preempt_wakeup+0xd9/0x1d0
g[1375589.787341] PGD 5da04067 PUD db83067 PMD 0 
g[1375589.788607] Oops: 0000 [#1] SMP 
g[1375589.788705] Modules linked in: veth xt_addrtype xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 ip_tables x_tables nf_nat nf_conntrack bridge stp llc aufs(C) softdog crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 processor psmouse parport_pc parport i2c_piix4 i2c_core thermal_sys lrw virtio_net evdev pcspkr serio_raw gf128mul glue_helper ablk_helper cryptd button ext4 crc16 mbcache jbd2 sd_mod crc_t10dif crct10dif_common virtio_scsi scsi_mod virtio_pci virtio virtio_ring
g[1375589.788705] CPU: 1 PID: 1515 Comm: docker Tainted: G         C    3.16.0-0.bpo.4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1~bpo70+1
g[1375589.788705] Hardware name: Google Google, BIOS Google 01/01/2011
g[1375589.788705] task: ffff88006fffc110 ti: ffff880003ac4000 task.ti: ffff880003ac4000
g[1375589.788705] RIP: 0010:[<ffffffff810a67d9>]  [<ffffffff810a67d9>] check_preempt_wakeup+0xd9/0x1d0
g[1375589.788705] RSP: 0018:ffff880003ac7e30  EFLAGS: 00010002
g[1375589.788705] RAX: 0000000000000001 RBX: ffff880073112ec0 RCX: 0000000000000002
g[1375589.788705] RDX: 0000000000000001 RSI: ffff880009156d20 RDI: ffff880073112f38
g[1375589.788705] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
g[1375589.788705] R10: ffffffffffffffe0 R11: 0000000000000000 R12: ffff88006d2dcd00
g[1375589.788705] R13: ffff88006fffc110 R14: 0000000000000000 R15: 0000000000000000
g[1375589.788705] FS:  000000000323a880(0063) GS:ffff880073100000(0000) knlGS:0000000000000000
g[1375589.788705] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
g[1375589.788705] CR2: 0000000000000078 CR3: 0000000034bff000 CR4: 00000000000406e0
g[1375589.788705] Stack:
g[1375589.788705]  0000000000000000 ffffffff00000000 ffff88000000006e ffff880073112ec0
g[1375589.788705]  ffff8800091573a4 0000000000000286 0000000000012ec0 ffff880073112ec0
g[1375589.788705]  0000000000000002 ffffffff8109cef4 ffff880009156d20 ffffffff810a01a4
g[1375589.788705] Call Trace:
g[1375589.788705]  [<ffffffff8109cef4>] ? check_preempt_curr+0x84/0xa0
g[1375589.788705]  [<ffffffff810a01a4>] ? wake_up_new_task+0xf4/0x1b0
g[1375589.788705]  [<ffffffff8118516d>] ? mprotect_fixup+0x15d/0x250
g[1375589.788705]  [<ffffffff8106d10f>] ? do_fork+0xcf/0x340
g[1375589.788705]  [<ffffffff8154b779>] ? stub_clone+0x69/0x90
g[1375589.788705]  [<ffffffff8154b40d>] ? system_call_fast_compare_end+0x10/0x15
g[1375589.788705] Code: 00 00 83 e8 01 4d 8b 64 24 70 39 d0 7f f4 48 8b 7d 78 49 3b 7c 24 78 74 1d 66 0f 1f 84 00 00 00 00 00 48 8b 6d 70 4d 8b 64 24 70 <48> 8b 7d 78 49 3b 7c 24 78 75 ec 48 85 ff 74 e7 e8 f2 f9 ff ff 
g[1375589.788705] RIP  [<ffffffff810a67d9>] check_preempt_wakeup+0xd9/0x1d0
g[1375589.788705]  RSP <ffff880003ac7e30>
g[1375589.788705] CR2: 0000000000000078
g[1375589.788705] ---[ end trace 5fab7713cb2d171f ]---

The only way I've been able to restore them is to login to the web interface and manually reset them. Needless to say, it doesn't scale.

I've already tried setting up a watchdog device and setting kernel.panic = 10, which in theory should reboot the VM.

For these VMs, I'm using the 'container-vm' as the OS flavor (i.e. Debian with Docker-preinstalled more or less).

Have anyone else seen this?

I can't seem to get watchdog's 'max-load-*' features working on Ubuntu 14.04 (in a Vagrant VM w/ Virtualbox).

From my understanding, it should be fairly straight forward. Here's how I'm testing it.

• I've set 'max-load-1' to 0.5 for testing purposes (and added -v -f to the start params) [1]
• Restart the watchdog service (service watchdog restart)
• Triggered burnP6 to simulate a heavily loaded server (the test VM only has one core, so it spikes pretty fast)

The expected result (to me) would be that the box would reboot after load average reaches 0.5, but it just goes on plateaus at around 1.

I've also experimented with the 'ping' feature, and that one works just like a charm. If I set it, and then removes the default gateway, the VM reboots as expected.

I've also tried adding the 'softdog' module and explicitly set 'watchdog-device = /dev/watchdog', but it doesn't seem to make any difference.

Am I missing something?

[1] watchdog.conf: https://gist.github.com/vpetersson/8487f45826216f556e89

I'm having some issues with Ansible and the way it defaults to values. What I'm trying to accomplish is to bind a Docker container to on eth1, if it exists, otherwise use lo.

My initial approach was to use the defaulting undefined variables as follows:

shell: docker run -d -p {{ ansible_eth1.ipv4.address | default(127.0.0.1) }}:27017:27017 [...] dockerfile/mongodb

Unfortunately, Ansible threw the following error.

fatal: [server] => One or more undefined variables: 'ansible_eth1' is undefined

I also tried versions of this, such as:

shell: docker run -d -p {{ ansible_eth1.ipv4.address | ansible_lo.ipv4.address }}:27017:27017 [...] dockerfile/mongodb

That gave me another error:

failed: [server] => {"changed": true, "cmd": "docker run -d -p {# ansible_eth1.ipv4.address | ansible_lo.ipv4.address #}:27017:27017 [...]", "delta": "0:00:00.021053", "end": "2014-11-01     17:22:04.457375", "rc": 127, "start": "2014-11-01 17:22:04.436322"}
stderr: /bin/sh: 1: ansible_lo.ipv4.address: not found
2014/11/01 17:22:04 Invalid containerPort: {{

Next up, I tried using the when and 'is not defined' condition instead. It's less DRY, as I need two stanzas then.

- name: Start Mongo on loopback
  shell: docker run -d -p {{ ansible_lo.ipv4.address }}:27017:27017 [...] dockerfile/mongodb
  when: ansible_eth1.ipv4.address is not defined

That gave me the following error:

error while evaluating conditional: ansible_eth1.ipv4.address is not defined

Any Ansible experts out there that can point me in the right direction?

Oh, and I'm running ton Ansible 1.7.2.

I've spent far too much time trying to figure this out now, and I could really need a pointer. The tl;dr is that I need to manually generate a certificate on one node, and then issue a certificate request over the API.

According to the official documentation, this should be rather straight forward. Here's what I did.

Generate a certificate for myhost.foobar.local (from client)

$ puppet cert generate myhost.foobar.local

Generate a CSR from the certificate (from client)

$ openssl req -new -key /var/lib/puppet/ssl/private_keys/myhost.foobar.local.pem -subj "/CN=myhost.foobar.local" -out request.csr

Issue a certificate request to the Puppet master (from client)

The API has been opened up for remote API calls, so we can make API call from the test node. However, I only get an error back.

$ curl -k -X PUT -H "Content-Type: text/plain" --data-binary @request.csr https://puppetmaster:8140/production/certificate_request/no_key
Could not intern from s: not enough data

Other calls works just fine, such as:

$ curl -k -H "Accept: pson" https://puppetmaster:8140/production/certificate_statuses/all
[
  {
    "state" : "signed",
    "fingerprints" : {
      "default" : "5A:35:D2:19:59:C6:6E:B8:BE:64:54:FA:14:10:CE:FC:4A:C8:45:F6:DE:8E:7C:E9:2D:B0:5B:E0:5D:93:35:DD",
      "SHA256" : "5A:35:D2:19:59:C6:6E:B8:BE:64:54:FA:14:10:CE:FC:4A:C8:45:F6:DE:8E:7C:E9:2D:B0:5B:E0:5D:93:35:DD",
      "SHA1" : "04:13:AF:B9:CB:44:01:64:24:C9:E0:D6:F4:0D:60:41:52:77:EE:45",
      "SHA512" : "2C:97:11:B9:ED:38:00:1F:B0:7B:75:ED:4C:DB:B1:3E:3D:63:09:C1:38:E2:A3:4F:50:A4:FD:71:FF:55:94:C3:7A:0B:F6:D5:79:09:6D:53:39:B1:EC:C2:BF:DF:CD:9B:67:60:B9:9C:0C:82:51:E9:23:30:AA:33:AC:8B:E9:94"
    },
    "name" : "puppet.foobar.local",
    "dns_alt_names" : [
      "DNS:puppet",
      "DNS:puppet.foobar.local"
    ],
    "fingerprint" : "5A:35:D2:19:59:C6:6E:B8:BE:64:54:FA:14:10:CE:FC:4A:C8:45:F6:DE:8E:7C:E9:2D:B0:5B:E0:5D:93:35:DD"
  },
  {
    "state" : "signed",
    "fingerprints" : {
      "default" : "32:7B:B3:4E:BE:EB:66:21:E5:96:D0:7B:BA:BF:1D:FC:D5:90:E1:6F:52:6B:AB:CF:98:7E:2A:E3:48:00:A2:CF",
      "SHA256" : "32:7B:B3:4E:BE:EB:66:21:E5:96:D0:7B:BA:BF:1D:FC:D5:90:E1:6F:52:6B:AB:CF:98:7E:2A:E3:48:00:A2:CF",
      "SHA1" : "A4:17:D3:05:8A:72:BE:6C:C2:0C:FA:C4:8A:3B:6E:C4:29:90:4B:95",
      "SHA512" : "2D:C3:EE:7E:E3:39:99:C8:21:B8:97:E8:BF:FE:62:26:A8:B8:63:30:C9:F1:77:80:DB:FC:DF:B8:ED:1E:A2:6C:C2:F9:FE:5D:CA:17:D9:08:1E:EB:AA:AF:3D:99:A6:F9:3D:E6:86:A0:B3:3F:E9:EC:1C:7F:25:95:B5:D6:7C:51"
    },
    "name" : "965c252e48c3",
    "dns_alt_names" : [

    ],
    "fingerprint" : "32:7B:B3:4E:BE:EB:66:21:E5:96:D0:7B:BA:BF:1D:FC:D5:90:E1:6F:52:6B:AB:CF:98:7E:2A:E3:48:00:A2:CF"
  }
]

(formatted for readability)

I'm not sure if I'm missing something here. All other API calls appears to work fine, including signing, and DELETE/revoke of nodes. It's just the certificate request call that appears to fail. Perhaps I'm missing something obvious.

The Puppet master is running '3.7.2-1puppetlabs'.

tl;dr: the new 2.6 replica eats up a lot more disk space than the 2.4 members.

We're heavy users of MongoDB's GridFS. We're currently on 2.4, and are intending to upgrade to 2.6 by simply adding a new replica members and gradually deprecate the 2.4 nodes as recommended.

We have one primary, one secondary and an arbiter. Here are some data on the current system:

$ mongod --version
db version v2.4.10
Sun Jul 27 13:56:27.250 git version: e3d78955d181e475345ebd60053a4738a4c5268a

Here's some data on the database:

> db.stats()
{
    "db" : "SomeDatabase",
    "collections" : 4,
    "objects" : 2797931,
    "avgObjSize" : 284877.9334958582,
    "dataSize" : 797068801344,
    "storageSize" : 946689860768,
    "numExtents" : 469,
    "indexes" : 5,
    "indexSize" : 251248480,
    "fileSize" : 950804676608,
    "nsSizeMB" : 16,
    "dataFileVersion" : {
        "major" : 4,
        "minor" : 5
    },
    "ok" : 1
}

As you can see, the database is ~950GB and fits (but barely) on the Primary and Secondary (which is 1TB of storage).

Since we're running low on storage, I gave the new node that I wanted to add to the system another 200G (i.e. 1.2TB).

Here's the MongoDB version from the new node:

$ mongod --version
db version v2.6.3
2014-07-27T12:01:21.242+0000 git version: 255f67a66f9603c59380b2a389e386910bbb52cb

After making it a member of the replica set it starts to sync just fine (like every other time we've rotated ReplicaSet members). This is where it gets weird. After syncing for a few hours, it reaches the expected database size (~950GB). However, it just simply continues after that until it finally fills up the entire disk and crashes.

Now, I know that 2.6 is a new version, but how come that the database on disk exceeds the ones on the Primary and Secondary? Any pointers would be very helpful.

I have a very strange issue with Puppet 2.7.18 (on a Raspberry Pi) that started all of the sudden. In simple terms, the agent only partially follows the 'server' directive in puppet.conf.

The following works:

$ sudo puppet agent -t --server my.puppet.server

but, if i instead set it in puppet.conf, it doesn't seem to follow it.

$ grep server /etc/puppet/puppet.conf
server=my.puppet.server

I even confirmed it with the genconfig variable, which appears to agree with the fact that it is properly configured:

$ sudo puppet agent --configprint server
my.puppet.server

The strange part is that when I'm running it without the explicit server argument, I get the following error repeated:

$ sudo puppet agent -t
[...]
err: /Stage[main]/MyModule::Puppet/File[some_file.sh]: Could not evaluate: getaddrinfo: Name or service not known Could not retrieve file metadata for puppet:///modules/MyModule/some_file.sh: getaddrinfo: Name or service not known at /etc/puppet/modules/MyModule/manifests/another_file.pp:31
[...]
err: Could not send report: getaddrinfo: Name or service not known

Can anyone offer any kind of insight or explanation to why such behavior would happen?

I got a KVM/Qemu setup that works great. Now I want to streamline the provisioning of new VMs.

The two obvious ways are to either clone an existing disk or install from scratch (with an automated preseed/kickstart).

In my tests, installing with a preseed/kickstart takes at least a few minutes from creation to up and running (even with local mirrors). The result is great, but it takes too long.

Cloning is obviously a lot faster, but it creates problems as soon as you need a bigger disk than the source.

Now, if it was just a one-off thing, it would have been trivial to boot it up and expand the disk by hand. However, I'm looking to do this in an automated fashion on first boot.

There are basically three tasks that needs to be performed:

• Expand the disk (fdisk/cfdisk etc)
• Resize the volume pool (in case of LVM)
• Expand the actual file system

While it would be possible to script this, I wanted to raise it here, since I doubt that I am the only one looking to do this in an automated fashion. The closest thing that I've found is raspi-config for the Raspberry Pi, which offers an automated tool for this.

I could of course lift the code from raspi-config, but it makes a lot of assumptions, so I was hoping that there might be a more universal tool available.

What is the recommended way of getting a list of all the nodes from within a Puppet template?

Let's say I have a load balancer running Nginx. Inside of the template, I want to generate a list of backend servers. For the sake of simplicity, let's say these app-servers have a hostname that matches 'appserver*'.

Currently, I define an array inside site.pp with each app-server, and use that as follows:

upstream www.foobar.com {
  <% appservers.each do |val| -%>
  server <%= val %>:80;
  <% end -%>
}

I'd like to do away with that manually defined array, and instead query Puppet.

I'm in the process of building the architecture for a new SMB. Some decisions have already been made, but I'm looking for some input from the community.

Basically, the fundamental problem I'm trying to solve is how to run the required Windows-applications on the clients.

The hardware I have to play with are as follows (already purchased):

• ~15 Mac Mini clients
• Two (relatively) powerful KVM/Qemu hosts (running Ubuntu)

The two primary alternatives I'm evaluating are either running Windows 7 in VMware Fusion and run the applications locally or spinning up a Windows-server (Win2k12) and use Terminal Server to run the applications on the server.

It should also be mentioned that some of the applications require local hardware (USB hardware locks and other peripherals). I know this works under Fusion, but I'm not too sure it will work under RDP.

While solutions like Citrix are appealing from a technical point of view, the pricing is simply too steep for such solution to be relevant.

We've already been running Fusion on the Mac Minis for evaluation for a few months, but the result isn't overwhelmingly impressive, and we've seen a fair number of crashes.

My question is really if anyone else have any similar experience and what the pros/cons they ran across were.

The primary benefit with running the remote desktop solution would be that in the future, thin clients could be used. Also, since no (essential) data would be stored on any individual node, they are more or less disposable.

Since the Snow Leopard support was dropped in VMware Fusion 4.1.1, I had to resort to Snow Leopard Server to QA software on Snow Leopard (since my desktop is running Lion). Installing developer seed of SL Server was pretty straight forward, but for some reason it refuses to update.

The version of Snow Leopard Server that Apple provide developers with is 10.6.0, but 10.6.8 is the latest version. Yet, the system cannot find any system updates. I even tried forcing the installation of the 10.6.8 Combo (1.1) package for Snow Leopard Server, but it simply refuses to install with the following error:

Mac OS X Server Update Combined can't be installed on this disk. The volume does not meet the requirements for this update.

I even tried installing the update from 10.6.0 -> 10.6.1, but it fails in the same way. Did I miss something?

I'm curious to how people are deploying FreeBSD's ports in their environment. I assume that most people using FreeBSD are indeed using Ports (and often portupgrade for upgrading with binaries). I am however interested in how you have this setup, as I'm not satisfied with how things work in recent versions. I'm now running FreeBSD 9.0 and are having issues.

I've set things up as follows:

• /usr/ports is shared via NFS from one node (with nightly 'portsnap fetch update').
• Each node mounts /usr/ports with read-write
• I've set "WRKDIRPREFIX=/usr/tmp" in /etc/make.conf on all nodes
• I've configured the Portsnap to use a local index by adding the following to /usr/local/etc/pkgtools.conf:

ENV['LOCALINDICES'] ||= '/var/db'

ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'

I can successfully run portupgrade -p package to build a package and then portupgrade -P package to install the binary on the other nodes.

Yet, sometime I receive the following issue: /var/db/INDEX.local:23265:dbm_store failed

I cannot think of any other optimizations I can do to the system, as the index now resides locally, and the only thing really exported is the ports-tree and nothing is ever written to there from the nodes.

With more and more companies switching to public cloud services, I'm curious what you guys' thoughts are on TCP/IP tuning in the cloud. Is it worth bothering with? Given that you don't have access to the host-server, you're somewhat limited I presume

Let's say for the sake of the argument that you're running three MongoDB-servers in a replica-set on FreeBSD or Linux that all sync over an internal network.

I'd also be curious if anyone made any actual performance benchmarks to back up their arguments. I benchmarked the various network drivers available for KVM/Qemu here, but I'm curious what the gurus here suggest to tune further.

I started playing around a bit with the tuning-recommendations as suggested over here, but interestingly enough I saw a decrease in performance, rather than an increase, but perhaps I didn't fully understand the tweaks.

Update: I did a few more benchmarks and posted the result here. Unfortunately the result wasn't really what I expected.

I'm pretty new to Puppet, but I really like it thus far. Right now I'm currently setting it up to automate a small architecture.

I have one problem though -- I want to remove a package, and ensure that it is stopped. To accomplish this, I have the following entry in my manifest:

package { 'supervisor':
    ensure => absent,
}

service { 'supervisor':
    ensure     => stopped,
    enable     => false,
    hasstatus  => true,
}

The problem with this is that once the manifest been applied to the node once, I get the following error upon next run:

debug: Service[supervisor](provider=debian): Could not find supervisor in /etc/init.d
debug: Service[supervisor](provider=debian): Could not find supervisor.sh in /etc/init.d
err: /Stage[main]/Screenly_core/Service[supervisor]: Could not evaluate: Could not find init script for 'supervisor'

Is there any way to do some kind of conditional statement, such that the stop-procedure only gets executed if the package was indeed present (and then run prior to the package removal)?

For a long time, I've been thinking about switching to RAID 10 on a few servers. Now that Ubuntu 10.04 LTS is live, it's time for an upgrade. The servers I'm using are HP Proliant ML115 (very good value). It has four internal 3.5" slots. I'm currently using one drive for the system and a RAID5 array (software) for the remaining three disks.

The problem is that this creates a single-point-of-failure on the boot drive. Hence I'd like to switch to a RAID10 array, as it would give me both better I/O performance and more reliability. The problem is only that good controller cards that supports RAID10 (such as 3Ware) cost almost as much as the server itself. Moreover software-RAID10 does not seem to work very well with Grub.

What is your advice? Should I just keep running RAID5? Have anyone been able to successfully install a software RAID10 without boot issues?

I'm trying to upgrade PostgreSQL 8.3 to 8.4 using Ports on FreeBSD (7.2). I found a few good guides, such as this one, but they won't work.

Upon running 'portupgrade -o databases/postgresql84-client postgresql-client' I get nothing. Not even an error. (I dropped the -f, since I already have the latest 8.3-client installed.)

Anyone care to offer a solution?

We're having permission problem with Git on FreeBSD. The setup is fairly straight forward. We have a few different repos on the same server. For simplicity, let's say they reside in /git/repo1 and /git/repo2.

Each repo is owned by the user 'git' and a self-titled group (eg. repo1). The repo is configured with g+rwX access.

Every user who commits to the repository is also member of the group for the repo (eg. repo1).

The Git repositories all have 'sharedRepository = group' set.

So far so good, all users can check out the code from the repositories, and the first user can commit without any problem. However, when the next user tries to commit to the repositories, he will receive a permission error.

We've been banging our heads with this issue for some time now, and the only way we've managed to resolve it is by running the following script between commits (which is obviously very inconvenient):

find /git/repo1 -type d -exec chmod g+s {} \;
chmod -R g+rwX /git/repo1
chown -R git:repo1 /git/repo1/
cd /git/repo1
git gc

Anyone got a clue to where the problem lies?