docs(howto): removed /var/lib/fdo requisite from serviceinfo-api-server

[tym2k1]

The HOWTO.md document mentions that files parsed through the serviceinfo-api-server should have their source_path variable located under the /var/lib/fdo directory. However, during onboarding, the process seems to work correctly even when the source_path is set to a different directory. Additionally, the code in serviceinfo-api-server/src/main.rs does not enforce this directory requirement.

[tym2k1]

Fixed the name of the commit
docs(howto): removed /var/lib/fdo requisite from serverinfo-api-server -> docs(howto): removed /var/lib/fdo requisite from serviceinfo-api-server

[nullr0ute]

Having it elsewhere may cause issues with SELinux and from a support PoV I would prefer us to have a default location here.

[7flying]

Having it elsewhere may cause issues with SELinux and from a support PoV I would prefer us to have a default location here.

@nullr0ute agreed, but the docs are also not completely right about this. We can either explain this better on the docs or enforce the usage of that default location on code.

[tym2k1]

I agree. My main concern is clarity for developers who are trying to integrate this service into their environments. If there's potential for issues when deviating from the /var/lib/fdo directory, it might be beneficial to have a more explicit warning or note in the HOWTO.md. From my understanding enforcing the use of '/var/lib/fdo' would force developers to contenerize this service which is a good practice but it might make the project less flexible for some uses.

[tym2k1]

Thank you for the fast response by the way :)

[nullr0ute]

From my understanding enforcing the use of '/var/lib/fdo' would force developers to contenerize this service which is a good practice but it might make the project less flexible for some uses.

I don't follow this point about containerisation, the /var/lib directory structure is used for services data for a very long time irrespective of containerisation or not.

[tym2k1]

I see your point regarding the /var/lib convention. What I was trying to convey is that there might be scenarios where developers run the app as a standalone process (as me right now during testing), rather than a systemd service. Enforcing the use of /var/lib could complicate matters in these cases. My mention of containerization was an offshoot of this thought. Thank you for bringing up the systemd context; it's essential to consider both use-cases.