search for: sjhoward

Hi All, We're using CTDB to cluster protocols over a large SAN and have had some pain related to a bit of a design flaw: we store CTDB and protocol-specific accounting files (recovery locks, state files, etc) on the same filesystem that we're offering through CTDB itself. This makes our front-end services pretty intolerant of flapping in the back-end filesystem, which is obviously not

Hi All, My group runs several Samba services in production and we are trying to determine our exposure level to this vulnerability. It is my understanding that, on success, this attack gives read/write access to both the "Local Security Authority" service and to the "Security Account Manager" database(s). From the reading that I've been doing, it looks as though the

Hi All, I've got a CTDB cluster, managing NFSv3 and Samba, sitting in front of a GPFS storage cluster. The NFSv3 piece is carrying some pretty heavy traffic at peak load. About once every three to four days, CTDB has been exhibiting behaviors that result in IP-failover between two nodes for reasons that are currently unknown. The exact chain of events has been a little different each time

Hi All, My site has two separate clustered Samba instances (managed by two independent CTDB instances) running over GPFS. In the last couple of weeks, we have seen a recurring issue that causes the `smbd` process in *one* of these instances to become unresponsive (as seen by CTDB), which results in flapping of CTDB and multiple IP takeover runs. The symptoms that we observe are: 1) Samba

Hi Jeremy, Thanks so much for your reply! As a matter of fact, we did just that around 3:45p yesterday when our CTDB cluster was unable to self-heal from the latest in this series of failover events. Here's how the situation went down: 1) We saw flapping identical to that described in my original post 2) After about 30 minutes of waiting, CTDB was just spinning with `smbd` repeatedly