pleroma/pleroma
pleroma/pleroma
Watch
3
6
Fork
You've already forked pleroma
 15
Code Issues 360 Pull requests 53 Projects Releases 1 Packages 13 Wiki Activity

Add Dockerfile #4905

Closed
pea wants to merge 0 commits from gitlab-mr-iid-1523 into develop
pull from: gitlab-mr-iid-1523
merge into: pleroma:develop
Conversation 5 Commits - Files changed -
pea commented 2019-08-03 04:21:22 +00:00
Member
Copy link

Not entirely sure about using the config/ directory to store docker.exs, so let me know if you have any better suggestions for that.

Running this live on https://ptest.pea.sh behind traefik (cherry-picked onto master to avoid some develop-only bugs futzing with things, but I've confirmed both to be working) and it seems to be working perfectly.

Would complete task 1 of #1147

Not entirely sure about using the config/ directory to store docker.exs, so let me know if you have any better suggestions for that. Running this live on https://ptest.pea.sh behind traefik (cherry-picked onto master to avoid some develop-only bugs futzing with things, but I've confirmed both to be working) and it seems to be working perfectly. Would complete task 1 of #1147
minibikini commented 2019-08-13 11:27:28 +00:00
Member
Copy link

How to overwrite/extend the default configuration?

Also, why generate vapid_details instead of using env vars?

How to overwrite/extend the default configuration? Also, why generate `vapid_details` instead of using env vars?
pea commented 2019-08-16 21:33:59 +00:00
Author
Member
Copy link

You can extend the default configuration by mounting a volume at /var/pleroma/ (which you should anyway for persistent secrets) and creating a config.exs, it's sourced after everything in docker.exs so it can overwrite any information.

As for the vapid bit, that's a keypair and normally generated in the config when creating an instance without user input anyway, while I could have it provided via environmental variables I couldn't think of a usecase where that would be a useful utility where it wouldn't make more sense to just modify secret.exs

You can extend the default configuration by mounting a volume at /var/pleroma/ (which you should anyway for persistent secrets) and creating a config.exs, it's sourced after everything in docker.exs so it can overwrite any information. As for the vapid bit, that's a keypair and normally generated in the config when creating an instance without user input anyway, while I could have it provided via environmental variables I couldn't think of a usecase where that would be a useful utility where it wouldn't make more sense to just modify secret.exs
pea commented 2019-08-16 21:36:09 +00:00
Author
Member
Copy link

it's worth noting there's one or two defaults I'm thinking of changing but haven't gotten to writing a MR for yet, this includes dynamic configuration and possible open registration, gonna make some time to talk to some folks in the irc channel about it though

it's worth noting there's one or two defaults I'm thinking of changing but haven't gotten to writing a MR for yet, this includes dynamic configuration and possible open registration, gonna make some time to talk to some folks in the irc channel about it though
minibikini commented 2019-08-20 10:46:15 +00:00
Member
Copy link

@pea, thanks for replying!

Sounds like unless there is a volume it would generate a new vapid config every time I run the image so a config volume is a requirement?

My current setup doesn't use volumes: secrets are stored in env vars and uploads in S3. I like this simplicity and would be happy to keep it so.

Some fairly complex apps like GitLab and Sentry are configurable via env vars. Would be great if it'd be possible to setup Pleroma with env vars only too.

Perhaps it worth to make the config volume optional for the cases where env vars are not enough (which I imagine would be rare since the defaults are reasonable and would probably suit the most instances)?

@pea, thanks for replying! Sounds like unless there is a volume it would generate a new vapid config every time I run the image so a config volume is a requirement? My current setup doesn't use volumes: secrets are stored in env vars and uploads in S3. I like this simplicity and would be happy to keep it so. Some fairly complex apps like GitLab and Sentry are configurable via env vars. Would be great if it'd be possible to setup Pleroma with env vars only too. Perhaps it worth to make the config volume optional for the cases where env vars are not enough (which I imagine would be rare since the defaults are reasonable and would probably suit the most instances)?
pea commented 2019-09-03 16:22:55 +00:00
Author
Member
Copy link

@egor I can look into this, but my main reason for not allowing it is that it would be significantly obtuse to generate vapid keys outside of the BEAM and convert them to a nice format to pass into the BEAM. Off the top of my head, it probably involves something like generating a keypair using openssl, removing the header and footer from the keypair, and joining the lines I suppose? Nothing too horribly difficult to put in a oneliner, but the reality is that there's not really much documentation on the mapping between the keys generated by erlang and pem files other than actual functions that do so, so I wouldn't be surprised if it's fairly roundabout.

Unless there's something I'm missing, I'm not going to make it a goal right this moment, though, sorry. If you can find an easier way to do it than what I'm envisioning then please get back to me with that and I'll do what I can to turn it into an MR for you, but it just seems quite difficult for minimal gain from what I'm seeing.

@egor I can look into this, but my main reason for not allowing it is that it would be significantly obtuse to generate vapid keys outside of the BEAM and convert them to a nice format to pass into the BEAM. Off the top of my head, it probably involves something like generating a keypair using openssl, removing the header and footer from the keypair, and joining the lines I suppose? Nothing too horribly difficult to put in a oneliner, but the reality is that there's not really much documentation on the mapping between the keys generated by erlang and pem files other than actual functions that do so, so I wouldn't be surprised if it's fairly roundabout. Unless there's something I'm missing, I'm not going to make it a goal right this moment, though, sorry. If you can find an easier way to do it than what I'm envisioning then please get back to me with that and I'll do what I can to turn it into an MR for you, but it just seems quite difficult for minimal gain from what I'm seeing.

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
AP C2S

   
AdminAPI

   
Breaking API
Affects clients

  
Breaks existing config

   
Check if still valid

   
Data Protection

   
Do not merge

   
Document in the changelog

   
Doing

   
Feature Request / Enhancement

   
MastoAPI

   
NL2
Improved Mobile Experience

  
NL4
Improved instance customization and QoL options

  
OStatus

   
OTP Releases

   
Refactor

   
Security

   
To Do

   
TwitterAPI

   
bug

   
complicated

   
confirmed

   
deps

   
discussion

   
documentation

   
easy

   
feature: to be merged in stable

   
fix: to be merged in stable

   
incident
Denotes a disruption to IT services and the associated issues require immediate attention

  
needs to be backported to maint

   
needs-changes

   
needs-info

   
needs-review

   
performance

   
regression

   
unclear
No labels
AP C2S
AdminAPI
Breaking API
Breaks existing config
Check if still valid
Data Protection
Do not merge
Document in the changelog
Doing
Feature Request / Enhancement
MastoAPI
NL2
NL4
OStatus
OTP Releases
Refactor
Security
To Do
TwitterAPI
bug
complicated
confirmed
deps
discussion
documentation
easy
feature: to be merged in stable
fix: to be merged in stable
incident
needs to be backported to maint
needs-changes
needs-info
needs-review
performance
regression
unclear
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
pleroma/pleroma!4905
No description provided.