Makefile mark config target NOTPARALLEL

[izissise]

config target depends on certs target being already completed, when running make with -j2, both target runs concurrently which leads to errors in config. Marking config as NOTPARALLEL prevent concurrency when config is running.

[cla-bot[bot]]

In order to contribute to a Nivenly Foundation project you must sign and agree to the CLA. Reply with @cla-bot check to check again.

[dmah42]

why not just change it to config: pki instead?

[izissise]

why not just change it to config: pki instead?

I just followed the getting started and got the error, I guess someone might want to re-setup the config without re-generating pkis?

[dmah42]

why not just change it to config: pki instead?

I just followed the getting started and got the error, I guess someone might want to re-setup the config without re-generating pkis?

ah right. the right way to fix this then is to define the expected output of pkis and have that replace the pkis target, and be a prereq for config. that way if they exist, it'll run fine and if they don't it'll generate them.

[izissise]

why not just change it to config: pki instead?

I just followed the getting started and got the error, I guess someone might want to re-setup the config without re-generating pkis?

ah right. the right way to fix this then is to define the expected output of pkis and have that replace the pkis target, and be a prereq for config. that way if they exist, it'll run fine and if they don't it'll generate them.

certs target calls hack/certgen, this would mean converting certgen script as a Makefile right?

[dmah42]

why not just change it to config: pki instead?

I just followed the getting started and got the error, I guess someone might want to re-setup the config without re-generating pkis?

ah right. the right way to fix this then is to define the expected output of pkis and have that replace the pkis target, and be a prereq for config. that way if they exist, it'll run fine and if they don't it'll generate them.

certs target calls hack/certgen, this would mean converting certgen script as a Makefile right?

not necessarily.. i mean maybe ideally but as a short term we "know" what certgen is going to do and what we need to be available for the config target.. we could just assume that certgen does the right thing.

[izissise]

This fixes the concurrency problem:

.PHONY: pki
pki: install-certs ## Alias for install-certs
.PHONY: certs
certs: ## Generate x509 mTLS certs in /pki directory
    mkdir -p pki
    ./hack/certgen
.PHONY: install-certs
install-certs: certs ## Install certs in /etc/aurae
ifeq ($(uid), 0)
    mkdir -p /etc/aurae/pki
    cp -v pki/* /etc/aurae/pki
else
    sudo -E mkdir -p /etc/aurae/pki
    sudo -E cp -v pki/* /etc/aurae/pki
endif
    @echo "Install PKI Auth Material [/etc/aurae]"

.PHONY: config
config: certs ## Set up default config
    mkdir -p $(HOME)/.aurae
    cp -v auraescript/default.config.toml $(HOME)/.aurae/config
    sed -i 's|~|$(HOME)|g' $(HOME)/.aurae/config
    mkdir -p $(HOME)/.aurae/pki
    cp -v pki/* $(HOME)/.aurae/pki

But, when running make config, hack/certgen will replace previous certs everytime

[dmah42]

This fixes the concurrency problem:

.PHONY: pki
pki: install-certs ## Alias for install-certs
.PHONY: certs
certs: ## Generate x509 mTLS certs in /pki directory
  mkdir -p pki
  ./hack/certgen
.PHONY: install-certs
install-certs: certs ## Install certs in /etc/aurae
ifeq ($(uid), 0)
  mkdir -p /etc/aurae/pki
  cp -v pki/* /etc/aurae/pki
else
  sudo -E mkdir -p /etc/aurae/pki
  sudo -E cp -v pki/* /etc/aurae/pki
endif
  @echo "Install PKI Auth Material [/etc/aurae]"

.PHONY: config
config: certs ## Set up default config
  mkdir -p $(HOME)/.aurae
  cp -v auraescript/default.config.toml $(HOME)/.aurae/config
  sed -i 's|~|$(HOME)|g' $(HOME)/.aurae/config
  mkdir -p $(HOME)/.aurae/pki
  cp -v pki/* $(HOME)/.aurae/pki

But, when running make config, hack/certgen will replace previous certs everytime

i think this is ok.. it also overwrites the config with the default every time. ie, this is probably wrong but it's at least consistently wrong.

[izissise]

Should be good :)