Stumped by shorewall.configs

Hi,

As far as I understand from:
https://search.nixos.org/options?channel=unstable&show=services.shorewall.configs&from=0&size=50&sort=relevance&type=packages&query=shorewall

You should specify configs as:

services.shorewall.configs = {
   "shorewall.conf" = '' config lines. ... '';
};

This however fails with:

error: value is the partially applied built-in function 'mapAttrs' while a set was expected

       at /nix/store/22aq7ifkxk95achgwbb8ygjklgcwygvn-source/lib/modules.nix:476:44:

          475|         options = {};
          476|         config = addFreeformType (addMeta (removeAttrs m ["_file" "key" "disabledModules" "require" "imports" "freeformType"]));
             |                                            ^
          477|       };
(use '--show-trace' to show detailed location information)
/run/current-system/sw/bin/nixos-container: failed to build container from flake '.'

Not sure what I’m missing here :confused:

Thanks,
Razvan

From the description that looks correct to me. If you figure it out please update the option to contain an example that demonstrates this more clearly.

@julm can you help out here?

Well I didn’t figure it out yet :frowning:
I hoped someone more experienced would jump in but my guess is no one really uses shorewall anymore :slight_smile:

OK a bit more headbanging and I came to:

    shorewall = { 
       enable = true;
       configs = {
           "shorewall.conf" ="LOG_MARTIANS=Yes\n"';
       };
     };

And that works! :upside_down_face:

That seems like a really poor/incorrect error message, considering types.lines can be used for either of those string creation syntaxes… :thinking:

Nothing fancy is being done in the module (types.attrOf types.lines), so not really sure what’s up.

Perhaps another issue with your configuration was causing this error?

IDK I was testing in a container build which was already working … anyway it’s working now so I’ve marked it as solved.

To clarify: you can’t reproduce this/provide an example which does reproduce this error, right? If not, that’s fine, but if you can I’d be interested in looking into it.

@winter I cannot replicate it anymore. I don’t know what was wrong with my setup but now it works. :see_no_evil: