As can be seen on this Picture by ESA/Hubble, they have – finally – discovered the God of Inappropriate Gestures.
I have no idea what’s going on. Some people seem to mention this behavior, but never there is any solution around. It’s only few people, so it looks like a configuration issue, and either it’s really rare or so common that I’m the last who didn’t get it yet. It’s as follows.
I have an experimental setup with a Samba 4 AD instance as Domain controller. The VM that demonstrates the bug is a samba 3.6.10 member server. Both are based on SerNet‘s builds (enterprisesamba and packages from the SerNet Samba 4 Appliance). Everything’s hosted on a Xen machine and made with debian squeeze as the base OS.
Rainbow Shield Bugs on Jatropha,
Ton Rulkens, Mozambique
Inside one share, I have a directory with some ACLs set, with the mask and default mask set to rwx. If I’m now creating a file using the shell, the file’s ACL mask becomes rw which is just correct. If I’m doing the same with samba, the mask will be rwx which is just plain wrong as the file would be executable like this.
I’ve tried many more or less random things like s-flags, samba parameters (inherit acls has no effect, it seems) and googled as described above, but this thing’s going consistently wrong.
Anybody around who knows more or is stunned like I am? Well, I didn’t expect to run into this issue, really not.
I’m giving back!
Whoever helps me to find an answer or even a fix can get some of my knowledge in the form of code: I offer a complete setup for Samba 4 and 3.6 experiments with Debian Squeeze. It incudes a debian packages source with all you need for such a (virtual) environment of this kind, such as an updated bind9 build and integratable S4 packages and a time saving xen-tools role script, which installs a DomU with these package sources, adding SerNet’s 3.6 (remote) sources as well, many often needed standard packages readily installed, /etc/hosts file adapted to the LAN environment, ethtools, NFS4 mounted from DomU (for easy data exchange between VMs, filesystem ACLs readily setup, and an A record added to a DNS zone file on the host system. So that’s all those repeated tasks after xen-create-image that usually take about 30 to 60 minutes every time to turn the installation into a comfortable, accessible and well integrated VM ready to dig into Samba’s Active Directory implementation details, and even taking steps towards a future production environment on a clean debian foundation (we’re not that far though, in my opinion).
Using this role and some more files in /etc/xen-tools/skel, it takes me 15 minutes for a S4-AD DC and a member server provisioned and up running, ready to join a Windows client and access with native AD management tools.
This is very unfortunate. Now that this complex server setup is finally ready, LVM starts to throw bugs. Setup is a volume group on a software RAID volume. I can create a snapshot of my Xen-DomU-Volumes, backup them, but as soon as I try to remove the snapshot with lvremove, the command just hangs, and so do all other LVM-commands, even lvs.
I’ve googled around a lot now, but with no results. Consequently, I can not backup my stuff at the moment.
Following a proposal to stop the udev deamon before lvremove, I didn’t get any further either, because this seems to break Xens ethernet bridges somehow (although this is really, really weird, it just shouldn’t!), while being helpful for the Backups. No solution.
And, all similar behavior I find googling relates to Kernel <2.6.16 and LVM2 <2.02. What the Fuck! 2006, 2007…
Anybody out there with the same problem? Or someone with an idea or solution? Anybody desiring more information? please report to me!
I hereby bid US-$60.00 for:
a working fix proposed the right information to develop a fix myself
So, if somebody can tell me, what’s going on here between LVM, udev and dm – don’t hesitate to use my contact form. Should your information result in a fix, you get $60. Should two individuals provide equivalent information, the first one wins.
EDIT/UPDATE Jan 2, 2012:
Problem tracked down to potential hardware issue! see comment below! And so far, Debians reputation fixed on approbation! 😉