Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation violation on FreeBSD 13.1 #620

Closed
ghost opened this issue Jan 6, 2023 · 11 comments · Fixed by #621
Closed

Segmentation violation on FreeBSD 13.1 #620

ghost opened this issue Jan 6, 2023 · 11 comments · Fixed by #621
Milestone

Comments

@ghost
Copy link

ghost commented Jan 6, 2023

I am trying to set up a fresh install of writefreely 0.13.2 on FreeBSD 13.1 (MySQL backend) and getting a segfault when trying to create an admin user (i selected the multi-user instance option during configuration).

The package is directly from FreeBSD repositories.
image

@thebaer
Copy link
Member

thebaer commented Jan 6, 2023

I'm able to replicate this if the pages directory is gone. We don't maintain the FreeBSD package, so this issue will need to be brought up with them to fix this particular installation issue.

As for us, I'll mark this as an error message issue, so we can print out something more user-friendly when this happens in the future.

thebaer added a commit that referenced this issue Jan 6, 2023
Previously, app would panic and admins would see unhelpful errors.

This closes #620
@thebaer thebaer added this to the 1.0 milestone Jan 6, 2023
@clausecker
Copy link

We do ship the pages directory, so I'm not sure what the specific problem is.

@ghost
Copy link
Author

ghost commented Jan 7, 2023

I'm able to replicate this if the pages directory is gone. We don't maintain the FreeBSD package, so this issue will need to be brought up with them to fix this particular installation issue.

The pages directory exists on my end.

@clausecker
Copy link

It is possible that the binary is looking for the pages directory in the wrong place. Following FreeBSD conventions, we are installing the binary into /usr/local/bin, whereas the files served by HTTP go to /usr/local/www. I'm currently investigating this.

@thebaer
Copy link
Member

thebaer commented Jan 23, 2023

@clausecker do you have static_parent_dir, pages_parent_dir, etc. set to /usr/local/www in the config file?

@clausecker
Copy link

@thebaer We have the user run the command

su -m "$writefreely_user" -c "/usr/local/bin/writefreely -c '$writefreely_config' config start"

to generate the configuration file. We do not edit the config file afterwards. A sample config file generated from this command looks like this:

[server]
hidden_host          = 
port                 = 8080
bind                 = localhost
tls_cert_path        = 
tls_key_path         = 
autocert             = false
templates_parent_dir = 
static_parent_dir    = 
pages_parent_dir     = 
keys_parent_dir      = 
hash_seed            = 
gopher_port          = 0

[database]
type     = sqlite3
filename = writefreely.db
username = 
password = 
database = 
host     = localhost
port     = 3306
tls      = false

[app]
site_name             = admin
site_description      = 
host                  = http://localhost:8080
theme                 = write
editor                = 
disable_js            = false
webfonts              = true
landing               = 
simple_nav            = false
wf_modesty            = false
chorus                = false
forest                = false
disable_drafts        = false
single_user           = true
open_registration     = false
open_deletion         = false
min_username_len      = 3
max_blogs             = 1
federation            = false
public_stats          = true
monetization          = false
notes_only            = false
private               = false
local_timeline        = false
user_invites          = 
default_visibility    = 
update_checks         = false
disable_password_auth = false

[oauth.slack]
client_id          = 
client_secret      = 
team_id            = 
callback_proxy     = 
callback_proxy_api = 

[oauth.writeas]
client_id          = 
client_secret      = 
auth_location      = 
token_location     = 
inspect_location   = 
callback_proxy     = 
callback_proxy_api = 

[oauth.gitlab]
client_id          = 
client_secret      = 
host               = 
display_name       = 
callback_proxy     = 
callback_proxy_api = 

[oauth.gitea]
client_id          = 
client_secret      = 
host               = 
display_name       = 
callback_proxy     = 
callback_proxy_api = 

[oauth.generic]
client_id          = 
client_secret      = 
host               = 
display_name       = 
callback_proxy     = 
callback_proxy_api = 
token_endpoint     = 
inspect_endpoint   = 
auth_endpoint      = 
scope              = 
allow_disconnect   = false
map_user_id        = 
map_username       = 
map_display_name   = 
map_email          = 

The writefreely daemon is started with its working directory being /usr/local/www/writefreely, which contains the pages, templates, and static directories. It starts and serves the blog just fine. Is there some extra configuration we need to perform?

@clausecker
Copy link

@realseb1g Does the problem still occur if you execute this command from /usr/local/www/writefreely?

@ghost
Copy link
Author

ghost commented Jan 23, 2023

The problem does not occur anymore when executing the command from /usr/local/www/writefreely.

@clausecker
Copy link

@realseb1g Thanks, I'll note this as a possible workaround. @thebaer what do you recommend we do to fix this? Is there an easy way to correctly set these configuration keys on initial config generation?

@thebaer
Copy link
Member

thebaer commented Jan 24, 2023

There isn't anything built in to the application to set those values. But the config process only alters values it asks about. So you could supply a default config.ini file with just the values you want populated, then when users run writefreely config start, the process will fill in the rest without overwriting them. For example:

[server]
templates_parent_dir = /usr/local/www
static_parent_dir = /usr/local/www
pages_parent_dir = /usr/local/www

@clausecker
Copy link

@thebaer That's a good idea! I'll go ahead and try that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants