search

DocCyblade / tkl-mayan-edms

Turnkey Linux - Mayan EDMS
https://www.turnkeylinux.org/mayan-edms
Other
4 stars 12 forks source link

Create new database password for mayan on first boot #39

Closed DocCyblade closed 7 years ago

DocCyblade commented 7 years ago

@JedMeister - Should be changing the password on first boot using init hook?

JedMeister commented 7 years ago

Do you mean the Mayan PGSQL user you have created? Assuming so, then probably, although it depends on how you set up the connection.. IMO it's legitimate to use a local Postgres user without a password (using a local unix socket to communicate with Posgres) although doing it in a similar way to MySQL (i.e. setting a user password) is probably better...

I should probably ask Alon what his preference is.

DocCyblade commented 7 years ago

Sounds good, let me know

DocCyblade commented 7 years ago

Looks like we did do this for Odoo so I am going to do this with Mayan, it makes sense to keep the password not known.

JedMeister commented 7 years ago

Oops, sry, I spoke with Alon about this too, but forgot to pass it on. From my notes:

Alon says best practice only!

And seeing as it was done for Odoo, let's keep it consistent.

DocCyblade commented 7 years ago

Sounds good, almost done with this one

DocCyblade commented 7 years ago

closes with 0c5a4a1

JedMeister commented 7 years ago

OT: FWIW if instead of writing (e.g.) "(Issue #55)" in your commit message, you write something like "closes #55" then when you merge the commit, it should auto close the issue.

Although TBH I'm not sure if it supports shutting multiple issues with single commits. As a general rule best practice dictates that only one issue/bug/tweak/etc should be addressed per commit. IMO it's not an issue while you are working on your own in a dev branch developing a new appliance, but probably worth knowing what appears to be the convention...

Personally when I'm developing I tend to commit almost every single change I make and then once I reach a point that I'm happy, I go back and squash them into more meaningful commits (i.e. I rewrite the history). Just a word of warning though, I only ever do it in my own dev branches and never on shared public repos (like turnkey). It can cause huge issues for others who have forked your work as once you squash commits then their fork's history no longer matches your repo's...

DocCyblade commented 7 years ago

Thanks for the info!