wzzrd's questions

I'm trying to run an amd64 UBI9 image on Apple silicon with Podman. Podman provides a Fedora CoreOS VM to run containers in. It allows for installing qemu binaries to run "foreign architecture" containers.

Problem is, the architecture of the UBI9 images is x86_64-v2 and the qemu-x86_64-static binary in the Fedora CoreOS VM does not support that (yet?).

That means that running said image results in an error:

➜ podman build -f Containerfile --platform linux/amd64 -t mycontainer:0.3 .
STEP 1/7: FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
STEP 2/7: RUN microdnf install -y python3 python3-pip
Fatal glibc error: CPU does not support x86-64-v2
Error: error building at STEP "RUN microdnf install -y python3 python3-pip": error while running runtime: exit status 127

From what I understand, setting an environment variable called QEMU_CPU to max in the VM might solve this, but I'm unsure how and where to set that variable for it to be picked up by the podman processes.

Anyone solved this already?

(I could have put this on the MacOS site, the Superuser site and stackoverflow.com, I guess, but I think it fits here best because of the specific knowledge required.)

Assume a machine has multiple management UIs, like for example Cockpit and Monit. Both can do SSL.

Do best practices dictate using distinct certificates for either service? Or is it OK to reuse a single certificate since both are maintained by the same team, and run on the same machine.

I assume two SSL enabled services maintained by two different teams would not reuse the SSL certificate?

It might be the time of night, but this is puzzling me. Picture the following.

[root@node1 acltest]# getfacl foo/
# file: foo
# owner: root
# group: testuser
user::rwx
group::r-x
other::---

[root@node1 acltest]# ls -la .
total 24
drwxr-xr-x  3 root root     4096 Feb  9 21:53 .
drwxr-xr-x 25 root root     4096 Feb  9 21:54 ..
drwxr-x---  2 root testuser 4096 Feb  9 21:53 foo
[root@node1 acltest]# setfacl -m m::rwx foo
[root@node1 acltest]# getfacl foo/
# file: foo
# owner: root
# group: testuser
user::rwx
group::r-x
mask::rwx
other::---

[root@node1 acltest]# ls -la .
total 24
drwxr-xr-x   3 root root     4096 Feb  9 21:53 .
drwxr-xr-x  25 root root     4096 Feb  9 21:54 ..
drwxrwx---+  2 root testuser 4096 Feb  9 21:53 foo
[root@node1 acltest]# su - testuser
[testuser@node1 ~]$ cd /acltest/foo/
[testuser@node1 foo]$ ls -la .
total 16
drwxrwx---+ 2 root testuser 4096 Feb  9 21:53 .
drwxr-xr-x  3 root root     4096 Feb  9 21:53 ..
[testuser@node1 foo]$ touch bar
touch: cannot touch `bar': Permission denied

In words: I create a directory foo, with mode 0750, root as owner and testuser as the group. (testuser is the private group of testuser, but that doesn't matter.)

The getfacl command correctly shows no ACL's on this directory and there is not mask yet. The mask will be set accordingly to the group permissions if I would add a named group or user now.

If I explicitly set the mask to rwx now, the group permissions as shown by ls change too. I know it happens the other way around (the mask changes when the group permissions change), but this seems puzzling.

The more puzzling because the getfacl output does not show the group permissions as rwx but - as said - ls does.

Which one is right? Apparently, the output of getfacl is right, because testuser cannot write to foo. As expected, by the way, because I did not grant the testuser group any permissions to do so.

It goes on. I cannot allow the testuser group write permissions on foo by just using chmod. I have to explicitly set an ACL using setfacl -m g:testuser:rwx foo to allow testuser to finally touch foo/bar.

Can someone explain the rationale behind the difference in the outputs of getfacl and ls? I know it can be tricky to have normal permissions go together with ACL's, but this seems plain wrong. (Though I expect to be missing something glaringly obvious ;))

I have already seen Why does chmod(1) on the group affect the ACL mask?

So I'm setting up this server right now that'll host multiple websites / domains. What are the current best practices with regard to DNS records? I admit to 'just having done something' up to now, which is pretty bad. Mea culpa. And though it has worked for me in the past, I'd like to know what the best way of doing things is, so here's a couple of questions about it:

1. I think it probably makes the most sense to setup the main hostname like this

   192.168.0.1   A      example.com
   192.168.0.1   A      host.example.com
   www           CNAME  example.com
   

   and then a single PTR record for 192.168.0.1 back to example.com. Should the www CNAME point to the example.com or to the host.example.com A records? What makes more sense and why?

2. Would it then make the most sense to create a CNAME for each Virtualhost on this server to the example.com A record (or the host.example.com A record), or to create individual A records for each Virtualhost to the main IP address?

3. The SMTP server on this host will identify itself as host.example.com. Is SPF uptake broad enough already that I can create an SPF record for each hosted domain and have that take care of other domains possibly rejecting mail from this host?

I'm seeing the weirdest thing here. I have a couple of RHEL3, 4 and 5 machines that validate user credentials through Kerberos with an Active Directoy domain controller as their KDC.

This works for all of my users, save one. There is one account that is unable to log into RHEL3 Linux machines and generates the following errors there:

May 31 13:53:19 mybox sshd(pam_unix)[7186]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.1  user=user
May 31 13:53:20 mybox sshd[7186]: pam_krb5: TGT verification failed for `user'
May 31 13:53:20 mybox sshd[7186]: pam_krb5: authentication fails for `user'

Other accounts, like my own, are fine:

May 31 17:25:30 mybox sshd(pam_unix)[12913]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.1  user=myuser
May 31 17:25:31 mybox sshd[12913]: pam_krb5: TGT for myuser successfully verified
May 31 17:25:31 mybox sshd[12913]: pam_krb5: authentication succeeds for `myuser'
May 31 17:25:31 mybox sshd(pam_unix)[12915]: session opened for user myuser by (uid=0)

As you can see, TGT validation fails. This only happens for this specific account, not for any other.

The failing useraccount's password has been reset, I inspected both user objects in Active Directory, but I see nothing out of the ordinary.

If I have the failing useraccount log into a RHEL4 or 5 box, there is not problem, so it must be RHEL3 specific, but the fact that only one account suffers from this, alludes me. Maybe someone has seen this before?

Various sources on the internet suggest relinking of Oracle binaries is necessary after each OS upgrade and / or patch.

I can understand relinking would be necessary when upgrading glibc. Some package likely do not to require relinking, some do, some I am not sure about:

• upgrading glibc -> I suppose relinking required
• upgrading vim -> I suppose no relinking required
• upgrading gzip -> I'm not sure
• upgrading kernel -> I'm not sure

Does anyone have a list, or can anyone point me to a list to what libraries Oracle actually links? I am not an Oracle DBA, so I am clueless about the Oracle linking procedure. I am not even sure I actually understand what Oracle is doing during the relinking: it's not really a common practice in binary software to do it's own linking after install, is it?

Anyway, to make a long story short: I have a couple of RHEL[345] boxes, that I need to apply some patches to. Most boxes run Oracle and I am wondering what patches would require relinking and what would not. A list as exhaustive as possible would be nice :)

In the MIT Kerberos implementation that comes with most Linux distributions, I can define what encryption type I want to use for ticket requests. I am not a Windows guy, but apparently, Kerberos as a whole offers a lot of options here and Windows AD only offers a subset of these.

Does anyone know the enctypes a current Windows 2003 Enterprise domain controller would accept and provide? I don't seem to be able to find a definitive list of this.

Update: I have been able distill that Windows does not support 3DES. And even though MS TechNet says Unix clients generally do not support RC4, even my RHEL3 clients do so nicely.

In the line of this question on StackOverflow and the completely different crowd we have here, I wonder: what are your reasons to disable SELinux (assuming most people still do)? Would you like to keep it enabled? What anomalies have you experienced by leaving SELinux on? Apart from Oracle, what other vendors give trouble supporting systems with SELinux enabled?

Bonus question: Anyone has managed to get Oracle running on RHEL5 with SELinux in enforcing targeted mode? I mean, strict would be awesome, but I don't that is even remotely possible yet, so let's stay with targeted first ;-)

On our Linux servers, we currently use HPs qla2xxx drivers, because it has multipathing (active/passive) built in.

The are, however, various other options, like Red Hats device-mapper-multipath with the stock qla2xxx drivers (multibus and failover) and things like SecurePath and PowerPath (both of which can do trunking, iirc).

Can someone tell me what the merits and demerits of the various options are (if I can ask such a question), besides the obvious fact that the {Secure,Power}Path options cost vast amounts of money? I'm mainly interested in the freely available options, like HPs qla2xxx vs. Red Hats multipathd and possible other open source solutions, but I would like to hear good reasons to go for the commercial solutions too.

UPDATE: I'll be benchmarking various options the coming few days (the average of 10 runs of iozone for each option (options being native qla2xxx failver, native qla2xxx multibus, HP qla2xxx failover)). I'll post a summary of results here for those interested.

I manage a couple of hundred Linux servers, most of which are HP, if they are not virtualized. Historically, we have installed the HP ProLiant Support Pack (PSP) since before I started working here. The PSP comes with usefull (?) stuff like the HP System Management Homepage - which I have never used, but a couple of my colleagues do regularly - and a bunch of drivers.

Some of these drivers, like the iLO kernel module, are not in the stock kernel we use, so it might be useful to install those. Other drivers though, like the cciss and qla2xxx drivers HP supplies, aren't that useful: they are in the stock kernel and have been for quite some time. Overwriting the stock drivers will probably void support from our vendor on several kernel subsystems of not the whole kernel. On the other hand, HP might not support certain issues if you do not use their drivers.

I tend to lean to not installing the HP drivers, but what do you think: is there a tempting reason to install HPs cciss, qla2xxx, e1000, tg3, bnx2 (etc.) drivers and overwriting the drivers provided in the stock kernel package?

Edit: 'tempting reason to install' must be big enough to mitigate the disgusting quality of the packages of the PSP, meaning I have to repackage them all manually in order to be able to install through a centralized method like RH Satellite.

I just bought a new 500GB external harddrive. Most of the time I only store operating system ISO's on those things and some movies. Large files anyway, well over 4GiB sometimes, so FAT is out of the question.

So, I'm left wondering. My old external harddrive was NTFS formatted, because it had to be able to connect to Windows boxen sometimes. This new harddrive will not have that requirement. Would NTFS still be the best option? Would one of the ext{2,3,4} filesystems be a good choice for a removable disk? Are there filesystems that I am unaware of that would fit the bill?

"The bill" here would be a stable filesystem that is able to survive an unclean disconnection, is quick, can handle files of over 4GiB and is able to be used on at least kernels 2.6.28 and up.

Update: I hadn't taken xfs into account, and it's large filesystem support is interesting. I'll take a look at the operating systems / kernels I am using (RHEL5, CentOS5, Ubuntu 9.04 and 8.04, Fedora11) to see if those kernels support xfs. I think I remember some of them (the distros) not supporting it by default, but then again, maybe I'm mistaking jfs for xfs here.

The sync option too, is interesting, but that would mean creating UDEV rules for this device on all of my machines, which is not a huge problem, but still something I'll have to keep in mind.

Finally, taken xfs and the sync option, I'm wondering whether the performance gain for xfs and the performance hit with the sync option would be noticeable over the - still rather limited - USB interface.