Time Machine

[tubbo]

Is it possible to configure fruit:time machine = yes for an SmbShare? I’m not sure I see a place to add arbitrary settings to the share like this…

[phlogistonjohn]

Good question. I had plans to add a way to inject arbitrary smb.conf options into the SmbShare CRs but so far we haven't had a chance to implement it.

If you're interested in adding it I'd be happy to guide you. Otherwise, it may be a while, but I haven't forgotten about that feature.

[tubbo]

I'd love to! My thought was to make it a string value in the resource like so:

---
apiVersion: samba-operator.samba.org/v1alpha1
kind: SmbShare
metadata:
  name: backups
  namespace: storage
spec:
  storage:
    pvc:
      name: backups
  commonConfig: time-machine
  attributes: |-
    fruit:time machine = yes

We'd also need a similar feature for SmbCommonConfig:

apiVersion: samba-operator.samba.org/v1alpha1
kind: SmbCommonConfig
metadata:
  name: time-machine
  namespace: backups
spec:
  attributes: |-
    mdns name = mdns
    vfs objects = fruit streams_xattr  
    fruit:metadata = stream
    fruit:model = MacSamba
    fruit:posix_rename = yes 
    fruit:veto_appledouble = no
    fruit:nfs_aces = no
    fruit:wipe_intentionally_left_blank_rfork = yes 
    fruit:delete_empty_adfiles = yes 

Thought about using something more "sophisticated" like a ConfigMap, but this feels more future-proof. It can be injected into the smb.conf as-is and if things change with Samba in the future, the SmbShare spec can stay the same.

It's a bit much in terms of config but I think if people end up using this feature it can be simplified to a config setting. If people are running k8s in their homelab and have macOS machines, it seems very likely that they'd want to store backups on a replicated and backed-up set of storage rather than a single machine.

[phlogistonjohn]

I had originally planned for a ConfigMap as well, see the original design doc but I think something like an inline key-value mapping would be simpler, and we can always come back to do a ConfigMap later.

I would go for a map rather than an inline string because the operator goes through the intermediate layer of samba-container which uses a JSON/YAML config rather than going straight to smb.conf. Docs for samba-container here and here and sambacc here (sambacc is the management tool embedded in samba-container). I think having key-value pairs would be much easier to merge into the sambacc compatible configuration structure.

Let me know if you have any questions/thoughts/feedback.

[tubbo]

Makes sense to me, now that I'm looking through the code a bit. So to recap, the share spec would look something like this:

---
apiVersion: samba-operator.samba.org/v1alpha1
kind: SmbShare
metadata:
  name: backups
  namespace: storage
spec:
  storage:
    pvc:
      name: backups
  commonConfig: time-machine
  attributes:
    'fruit:time machine': yes

And for the common config:

---
apiVersion: samba-operator.samba.org/v1alpha1
kind: SmbCommonConfig
metadata:
  name: time-machine
  namespace: backups
spec:
  attributes:
    'mdns name': mdns
    'vfs objects': fruit streams_xattr  
    'fruit:metadata': stream
    'fruit:model': MacSamba
    'fruit:posix_rename': yes 
    'fruit:veto_appledouble': no
    'fruit:nfs_aces': no
    'fruit:wipe_intentionally_left_blank_rfork': yes 
    'fruit:delete_empty_adfiles': yes

[phlogistonjohn]

Looks pretty good. One request is to rename attributes to customAttributes or customConfigValues or the like. This is put some emphasis that the operator is just passing through these user-chosen smb.conf params. Hope that makes sense!