Michael Kohne's questions

I've got a test installation of Titra on a local system, and I've got it answering http on port 80 with this docker-compose file:

version: "2.0"
services:
  titra:
    image: kromit/titra
    container_name: titra
    depends_on:
      - mongodb
    environment:
      - ROOT_URL=http://timesheet
      - MONGO_URL=mongodb://mongodb/titra
      - PORT=3000
    ports:
      - "80:3000"
    restart: always
  mongodb:
    image: mongo:4.4
    container_name: mongodb
    restart: always
    volumes:
      - /root/titradb:/data/db

That works, but I'd kind of like the thing to answer https instead, but I'm not that familiar with Titra itself, nor Meteor (the framework it's written in), and my poking around the available documentation hasn't turned up anything about https for self-hosted Titra instances.

I'm trying to configure my pfSense box (running 2.5.2-RELEASE) to use my RADIUS server for admin login authentication.

My RADIUS server challenges for a TOTP code after getting the correct password, and this is working correctly (I have a number of other systems here using it for login).

I've configured my pfSense box with a RADIUS server (User Manager->Authentication Server) and I've set pfSense to try to authenticate via the RADIUS server (User Manager->Settings, select the RADIUS server).

If I watch the activity on the RADIUS server, I can see pfSense asking for authentication, and then the RADIUS server replying with a challenge for the TOTP code. pfSense doesn't appear to be able to deal with the challenge.

Is there anyway to get pfSense to do the right thing here? Or do I have to add support for entering the TOTP code with the password to my RADIUS server?

I've got my backup server reporting the age of the last successful backup to Prometheus, and I alert when that gets too old. I've just permanently shut down a server, and of course Prometheus is now alerting.

What's the correct way to deal with this? I could modify the alert such that it ignores that server, but I'm thinking that there's probably a better way to deal with this situation.

We use ProxMox (currently version 4.1-1) on a couple of servers here, and this morning I screwed up and shut down the entire system when I meant to shut down a VM. I'd like to avoid doing so in the future, and I'm willing to jump through extra hoops to shut down the system.

If I remove the 'Sys.PowerMgmt' from all Roles, are there any consequences BEYOND not being able to stop/start/restart/shutdown the node from the web UI?

If I need to shutdown the system, I'll simply ssh in or login at the console and issue 'shutdown -h now'.

Is there any downside to this plan that I'm unaware of? It looks like a good compromise to me, but I've long experience with not seeing all the flaws in my own plans.

I've got an older vendor-supplied package that I'm trying to install on CentOS 7. It installs things into /usr/lib, but there's a conflict with the /usr/lib directory itself.

The /usr/lib directory as installed:

ls -ld /usr/lib
dr-xr-xr-x. 42 root root 4096 Jun 10 08:44 /usr/lib   

The /usr/lib directory as specified in the package:

rpm -qlpv <package file>
drwxr-xr-x    2 root    root  0 Jun 22  2006 /usr/lib

I could use --replacefiles with rpm to get it to go on, but that's not actually the RIGHT thing to do here. Instead, I'd like rpm to just skip installing the /usr/lib directory (it's already there, after all), and just install the contents.

The --excludepath option doesn't actually seem to do anything (I still get the error), and (according to -vv output) would exclude most of the package anyway.

For the moment, in a test environment, I can do --replacefiles, but I feel there must be some 'more correct' way to deal with this situation.

NOTE: Getting an updated vendor package IS on my TODO list, but isn't going to happen for some time, so I need a better near-term solution.

I've got two ProxMox servers and when I moved one of my VMs, it's running into performance issues.

ProxMox 3.4 running on Intel Xeon E5606 (2 CPUs, 4 cores each, @2.13 GHz). ProxMox 4.1 running on Intel Xeon E5-2650L v3 (2 CPUS, 24 cores each, @1.8GHz)

I've moved two VMs from the 3.4 server to the 4.1 server (I did backup on the 3.4, restore on the 4.1).

VM 816 seems to perform about the same, but VM 814 has taken a major performance hit (it now takes 4-6 minutes to boot).

Interesting things about them:

• Both have the older 'coreduo' processor.
• 814 is running Fedora Core 6.
• 816 is running CentOS 6.
• 814 is using ide for it's HD.
• 816 is using virtio for it's HD.
• both have their HD's set to no cache.

Obviously the immediately visible difference is that one is ide and one is virtio. But they were exactly this way on the old server - why is the one so much slower on the new server? I did try switching 814 to virtio, but then it doesn't boot.

What's most important to find out is whether this is something related to the newer version of KVM on ProxMox 4.1. I'm planning to upgrade the older server to the latest proxmox, but if it's going to break my VMs that's going to be a problem.

uname -a from VM 814: Linux SWBuild-Fedora.moberg 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux

uname -a from VM 816: Linux SWBuild-CentOS 2.6.32-71.el6.i686 #1 SMP Fri Nov 12 04:17:17 GMT 2010 i686 i686 i386 GNU/Linux

KVM lines obtained from ps:

/usr/bin/kvm -id 814 -chardev socket,id=qmp,path=/var/run/qemu-server/814.qmp,server,nowait -mon chardev=qmp,mode=control -vnc unix:/var/run/qemu-server/814.vnc,x509,password -pidfile /var/run/qemu-server/814.pid -daemonize -smbios type=1,uuid=709a3672-bb7e-40a8-9815-69129f612924 -name SWBuild-Fedora -smp 1,sockets=1,cores=1,maxcpus=1 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -vga cirrus -cpu coreduo,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 512 -k en-us -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:1a1a811322d -drive file=/var/lib/vz/images/814/vm-814-disk-1.raw,if=none,id=drive-ide0,format=raw,cache=none,aio=native,detect-zeroes=on -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -netdev type=tap,id=net0,ifname=tap814i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown -device e1000,mac=7A:9F:7F:7C:08:BA,netdev=net0,bus=pci.0,addr=0x12,id=net0

/usr/bin/kvm -id 816 -chardev socket,id=qmp,path=/var/run/qemu-server/816.qmp,server,nowait -mon chardev=qmp,mode=control -vnc unix:/var/run/qemu-server/816.vnc,x509,password -pidfile /var/run/qemu-server/816.pid -daemonize -smbios type=1,uuid=06458c85-061e-4783-9152-e0d7f8a9685d -name SWBuild-CentOS -smp 1,sockets=1,cores=1,maxcpus=1 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -vga cirrus -cpu coreduo,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 512 -k en-us -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:1a1a811322d -drive file=/var/lib/vz/images/816/vm-816-disk-1.raw,if=none,id=drive-virtio0,format=raw,cache=none,aio=native,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -netdev type=tap,id=net0,ifname=tap816i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown -device e1000,mac=F6:CE:EE:91:65:2B,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300

NOTES: Changing the OS on 814 is not really an option - this VM was built from an image taken from real-world hardware so that we could preserve it. It's used to build for some of our older systems, and we really don't have the time to validate a modified build system.

UPDATE: Probably the root of the problem is differences in the RAID cards on the two servers. When speccing the newer server another admin remembered us NOT having the flash module for the RAID card, so we specced the new server in the same way.

Further investigation shows that we DO have the flash module in the old server, and that it IS active, providing write caching. This, coupled with different access patterns, is likely the root of the performance difference.

I recently had an XFS filesystem become corrupt due to a powerfail. (CentOS 7 system). The system wouldn't boot properly.

I booted from a rescue cd and tried xfs_repair, it told me to mount the partition to deal with the log.

I mounted the partition, and did an ls to verify that yes, it appears to be there. I unmounted the partition and tried xfs_repair again and got the same message.

What am I supposed to do in this situation? Is there something wrong with my rescue cd (System Rescue CD, version 4.7.1)? Is there some other procedure I should have used?

I ended up simply restoring the system from backups (it was quick and easy in this case), but I'd like to know what to do in the future.

I've got an older system (Fedora Core 6, it's an isolated system used to do builds for older devices). I'm trying to build a matching VM, and I've noticed a difference I can't explain.

Both systems have the package glibc-2.5-3 on them, which includes the file /lib/libc-2.5.so.

The rpm -qi glibc output matches exactly on both systems.

On both systems, rpm -Vv says everything is fine (........ /lib/libc-2.5.so).

The md5sum of the file on the two systems DO NOT MATCH. (

When I do an objdump -x of the file on the two systems, I get DIFFERENT start address values, confirming that in fact the two SO files are different.

So, why does rpm -V tell me that the md5sum matches, when it clearly doesn't? How is it that these libraries became different?

I work for a company that uses standard 2.5" SATA HD's in our product. We presently test them by running the Linux 'badblocks -w' command on them when we get them - but they are 160 gig drives, so that takes like 5 hours (we boot parted magic onto a PC to do the scan). We don't actually build that many systems at a time, so this doable, but seriously annoying.

Is there any research or anecdotal evidence on what a good incoming test for a hard drive should be? I'm thinking that we should just wipe them with all zeros, write out our image, and do a full drive read back. That would end up being only about 1 hour 45 minutes total.

Given that drives do block remapping on their own, would what I've proposed show up any infant mortality just as well as running badblocks?

I'm looking for a script that will allow me to programatically modify logrotate configuration files. At the least I'd like it to be able to replace a block such as

/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

with a new block given on the command line or via stdin or via file (I don't care which). It must be able to operate on arbitrary config files.

I'd really like it if it understood the configuration enough that I could say something like

logrotateupdate /etc/logrotate.conf /var/log/wtmp weekly

and have it do the right thing (remove the monthly and replace it with weekly in the above example).

This may be something that's commonly known to others, but it's something I've never seen.

My system is linux (Ubuntu).

I'm currently working with an embedded system that uses Postgresql for data storage. We currently have a problem where the boxes will sometimes get rebooted with no warning, and no proper shutdown. This obviously leaves us with database problems in some cases (invalid page header in certain high-traffic tables is the most common symptom).

What I want to know is, what's the easiest way to clear the errors? I'm obviously going to lose data, but since the errors usually occur in tables that have ephemeral data in them, I don't really care, I just want to get the system back into operation.

Right now our procedure is to drop and re-create any afflicted tables. Is there anything else that we could do that would be faster? As I said, I'm OK with losing any data on the affected page, I just want the thing up and running.

Platform is Ubuntu 7.04, Postgresql 8.2 (We can't force an upgrade onto the customer right now). Filesystem is ext3, on a 2 gig CF card.

Obviously, fixing the unexpected reboots is my top priority, but progress on that is slow (it's hard to reproduce in the lab). In the meantime, I'm hoping for a simpler solution that will let our field people deal more quickly with the issues that do arise.