Hi,
I just installed a new pod and I installed it under a virtual host but the configuration automagically picked
up the physical machine name. Of course no other pods can talk to it that way so I tried to fix by setting
the url in diaspora.yml, but if I do so it will not start.
Not setting configs we explicitly highlight as very important is not a good idea. If you set a value and diaspora* fails to start, then you most likely made a syntax error. Please share the error you’re seeing.
Also, quoting that config file:
DO NOT CHANGE THIS AFTER INITIAL SETUP! […] If you do change the URL, you will have to start again as the URL will be hardcoded into the database.
And that’s not a joke.
I guess you didn’t bother to read the full message so I will repeat. I installed diaspora on a virtual machine, https://diaspora.eskimo.com/, but it for some reason picked up the name of the physical host it is on, “ftp.eskimo.com”, but it can not be reached from the outside by this name so it is not good, so I
HAVE TO, as in NOT FUCKING OPTIONAL, change the URL. Now, I get that I have to create a new database, I do NOT know how to do that. Can someone help me with this?
a) Treat everyone with respect, or you’ll have a really bad, and really short, time here.
b) There is no reason to spam multiple threads.
c) RAILS_ENV=production bundle exec rake db:drop db:create db:migrate will drop the database and create a new one.
I am not trying to spam multiple threads, I am not familiar enough with navigation on this system to know where I am. I am sorry to appear disrespectful but dismissive replies with “we told you not to do that”, without bothering to understand why is not helpful. It IS frustrating. Thank you for the somewhat more detailed response.
RAILS_ENV=production bundle exec rake db:drop db:create db:migrate
rake aborted!
Psych::SyntaxError: (/misc/www/diaspora/diaspora/config/diaspora.yml): did not find expected key while parsing a block mapping at line 26 column 1
/misc/www/diaspora/diaspora/vendor/bundle/ruby/2.6.0/gems/configurate-0.3.1/lib/configurate/provider/yaml.rb:20:in `initialize'
/misc/www/diaspora/diaspora/vendor/bundle/ruby/2.6.0/gems/configurate-0.3.1/lib/configurate/lookup_chain.rb:21:in `new'
/misc/www/diaspora/diaspora/vendor/bundle/ruby/2.6.0/gems/configurate-0.3.1/lib/configurate/lookup_chain.rb:21:in `add_provider'
/misc/www/diaspora/diaspora/config/load_config.rb:29:in `block in <top (required)>'
/misc/www/diaspora/diaspora/vendor/bundle/ruby/2.6.0/gems/configurate-0.3.1/lib/configurate.rb:69:in `instance_eval'
/misc/www/diaspora/diaspora/vendor/bundle/ruby/2.6.0/gems/configurate-0.3.1/lib/configurate.rb:69:in `create'
/misc/www/diaspora/diaspora/config/load_config.rb:19:in `<top (required)>'
/misc/www/diaspora/diaspora/config/boot.rb:8:in `require_relative'
/misc/www/diaspora/diaspora/config/boot.rb:8:in `<top (required)>'
/misc/www/diaspora/diaspora/config/application.rb:3:in `require_relative'
/misc/www/diaspora/diaspora/config/application.rb:3:in `<top (required)>'
/misc/www/diaspora/diaspora/Rakefile:10:in `require'
/misc/www/diaspora/diaspora/Rakefile:10:in `<top (required)>'
/misc/www/diaspora/diaspora/vendor/bundle/ruby/2.6.0/gems/rake-12.3.3/exe/rake:27:in `<top (required)>'
/misc/www/diaspora/.rvm/gems/ruby-2.6.5@diaspora/bin/bundle:23:in `load'
/misc/www/diaspora/.rvm/gems/ruby-2.6.5@diaspora/bin/bundle:23:in `<main>'
/misc/www/diaspora/.rvm/gems/ruby-2.6.5@diaspora/bin/ruby_executable_hooks:24:in `eval'
/misc/www/diaspora/.rvm/gems/ruby-2.6.5@diaspora/bin/ruby_executable_hooks:24:in `<main>'
(See full trace by running task with --trace)
I literally asked you to tell us the error message you’re seeing:
Because fixing the config is actually the first step - before creating a new database. But yeah, sure, I’m the one who “didn’t bother to read the full message”. 
But oh well, at least you did that now.
From the error, it looks like line 26 could have additional whitespace. That line should be just a configuration: ## Section, without any spaces in the beginning. But you shouldn’t even be touching that line. Ideally, you’d just copy the example into a new file, as instructed by the install docs, and change only the lines you need.
Unfortunately, the current stable version still uses a config file format that has significant indentation, so make sure you do not remove or add any spaces at the beginning of the file. In the case of #url: "https://example.org/", just remove the # and change the value - do not remove or add any spaces in the beginning of that line.
If you can’t figure it out, you can also share your modified config file here and we can check what’s wrong. Just make sure to remove your mail passwords and third-party API credentials when doing so.
Sorry but I am confused. Ok, but I see no difference in the first 26 lines between the example and my config:
Example:
## Some notes about this file:$
## - All comments start with a double #$
## - All settings are commented out with a single #$
## To change the default settings, you need both to uncomment the lines$
## AND, in most cases, to change the value that is given.$
## - Take care to keep proper indentation, that is by simply deleting$
## the original #, with no additional space before the setting's name.$
## - Take care to keep proper quoting. All ' must have a matching ' at$
## the end of the same line. The same goes for "$
## - Lines containing "## Section" are section headings. Do not edit them!$
## - Lists need the space after the -$
## - The values true, false and numbers should have no quote marks.$
## Single words don't need quote marks, but it doesn't do any harm to have them.$
##$
## You can set and/or override all these settings through environment variables$
## with the following conversion rules:$
## - Strip the top level namespace (configuration, production, etc.)$
## - Build the path to the setting, for example environment.s3.enable$
## - Replace the dots with underscores: environment_s3_enable$
## - Convert to upper case: ENVIRONMENT_S3_ENABLE$
## - Specify lists/arrays as comma-separated values$
##$
## - For example, on Heroku:$
## heroku config:set SERVICES_TWITTER_KEY=yourkey SERVICES_TWITTER_SECRET=yoursecret$
$
configuration: ## Section$
$
## You need to change or at least review the settings in this section$
## in order for your pod to work.$
environment: ## Section$
And my config:
# Some notes about this file:$
## - All comments start with a double #$
## - All settings are commented out with a single #$
## To change the default settings, you need both to uncomment the lines$
## AND, in most cases, to change the value that is given.$
## - Take care to keep proper indentation, that is by simply deleting$
## the original #, with no additional space before the setting's name.$
## - Take care to keep proper quoting. All ' must have a matching ' at$
## the end of the same line. The same goes for "$
## - Lines containing "## Section" are section headings. Do not edit them!$
## - Lists need the space after the -$
## - The values true, false and numbers should have no quote marks.$
## Single words don't need quote marks, but it doesn't do any harm to have them.$
##$
## You can set and/or override all these settings through environment variables$
## with the following conversion rules:$
## - Strip the top level namespace (configuration, production, etc.)$
## - Build the path to the setting, for example environment.s3.enable$
## - Replace the dots with underscores: environment_s3_enable$
## - Convert to upper case: ENVIRONMENT_S3_ENABLE$
## - Specify lists/arrays as comma-separated values$
##$
## - For example, on Heroku:$
## heroku config:set SERVICES_TWITTER_KEY=yourkey SERVICES_TWITTER_SECRET=yoursecret$
$
configuration: ## Section$
$
## You need to change or at least review the settings in this section$
## in order for your pod to work.$
environment: ## Section$
I use 1,30l in ex so you could see end of line as well. The ‘$’ aren’t in the actual file, they are the editor
showing end of line.
Yeah, that looks right. It’s quite possible that the parser gets confused by a syntax error later in the file, it appears like there are some edge-cases to the YAML parser in use here. Do a diff between your file and the example, and pay attention to whitespace.
Note: You can use tripple backticks (`) to enclose the configs, like so
```
your pasted stuff
```
which makes them a lot easier to read.
I am not seeing any whitespace changes, only removal of # to uncomment and change.
diff diaspora.yml diaspora.yml.example
39c39
< url: "https://diaspora.eskimo.com/"
---
> #url: "https://example.org/"
45c45
< certificate_authorities: '/etc/ssl/certs/ca-certificates.crt'
---
> #certificate_authorities: '/etc/ssl/certs/ca-certificates.crt'
171c171
< federation: true
---
> #federation: true
186c186
< rails_environment: 'production'
---
> #rails_environment: 'development'
612c612
< enable: true
---
> #enable: true
615c615
< sender_address: 'diaspora@eskimo.com'
---
> #sender_address: 'no-reply@example.org'
619c619
< method: 'smtp'
---
> #method: 'smtp'
627,628c627,628
< host: 'mail.eskimo.com'
< port: 25
---
> #host: 'smtp.example.org'
> #port: 587
633c633
< authentication: 'none'
---
> #authentication: 'plain'
642c642
< starttls_auto: true
---
> #starttls_auto: true
645c645
< domain: 'diaspora.eskimo.com'
---
> #domain: 'smtp.example.org'
650c650
< openssl_verify_mode: 'peer'
---
> #openssl_verify_mode: 'none'
668c668
< account: "nanook"
---
> #account: "podmaster"
671c671
< podmin_email: 'nanook@eskimo.com'
---
> #podmin_email: 'podmin@example.org'
684c684
< send: true
---
> #send: false
686c686
< url: 'https://relay.iliketoast.net/receive/public'
---
> #url: 'https://relay.iliketoast.net/receive/public'
690c690
< subscribe: true
---
> #subscribe: false
695c695
< scope: all
---
> #scope: tags
699c699
< include_user_tags: true
---
> #include_user_tags: false
709c709
< redis: 'redis://localhost:6379'
---
> #redis: 'redis://production.example.org:6379'
713c713
< redis: 'redis://localhost:6379'
---
> #redis: 'redis://production.example.org:6379'
diaspora@ftp:~/diaspora/config$
Look again at the first difference. 
There are four spaces missing in front of the URL key. Everything else looks fine.
Ah, don’t know how I didn’t see that! Thanks, I’ll go fix that.
Ok, fixed that, ran the original command you gave me, now diaspora does start and run, but I still have stuff in queue from when it was ftp.eskimo.com, how can I get rid of that?
What do you mean by queue? Background jobs?
Yes but I saw I could just tick the check box and select delete, now they are all gone. Now to see if it will talk to other nodes…
And forgive my terminology, I am calling pods nodes mistakenly, my bad. Other pods.
No worries, we also like to use the terms interchangeably if we want to make sure people understand what we’re talking about.
You could have just ignored those jobs, as all the data they want to access is no longer there, so they’d just fail forever until they’ve reached their retry limit. But sure, deleting them is also fine.
Also, if the pod URL you shared (https://diaspora.eskimo.com/) is your pod, then you did not delete the database. https://diaspora.eskimo.com/posts/1 is a post created 4 days ago - that makes no sense unless your server’s time is out of sync.
Do you have some kind of caching set up? https://diaspora.eskimo.com/.well-known/host-meta.xml still returns the old URL, which makes no sense whatsoever.
Ok well you are right as near as I can tell I did not delete the database, because I still have my account and posts there. However, diaspora DOES start with the URL configured now where it did not before, and I did run the commands you gave me.
I was able to send e-mail from my friendica node to my diaspora node.