"Failed to create swap, sorry!"

(Jay Pfaffman) #30

Yes. Sso works just fine across multiple servers-that’s pretty much the point of it.

You can have multiple sites use discourse as the SSO master.

What think you want is to leave all of your WordPress sites alone and add discourse on digital ocean. I’m working on a tool akin to cpanel that’ll let you manage some discourse functions, but it’s not ready yet.

As mentioned above you can get me to install for you (literatecomputing.com) & there’s a digital ocean referral code on my site that’ll give you a $10 credit.



Different domains though, right? My users will go from mydomain.com to discourse.myotherdomain.com ? Seems a bit seamy.

That issue aside, let me describe the kind of thing i want to do, and maybe let me know if it’s possible with Wordpress + Discourse + Other Things.

A visitor goes to a page on my site (whether Wordpress or otherwise). i check logged in status, and if logged in, i check the hasCarrot flag the database associated with that user. If true, i serve up a jpg of a carrot. If false, an empty carrot jar jpg.

If the user clicks the carrot image, the user unlocks a carrot badge on Discourse (and i flag hasCarrot to false in the db). (Can i do that? Can i have badge hooks external to Discourse?)

So yeah - that’s it. 1) Check logged in status, 2) react in various ways based on conditions of non-Discourse-native database entries (in a db tied to Discourse membership), and 3) hook into the badge system outside of Discourse.


(Jeff Wong) #32

Honestly, I much prefer subdomains to pathing different webapps. As long as it falls under *.mydomain.com, I’m inclined to trust it the same. While discourse supports being subpathed (and it’s possible to proxy through one domain to another), I would advise against going down that route.

The badge is definitely possible to do. You can just hook into discourse via its API.


(Jay Pfaffman) #33

They can go from your.com to discourse.your.com. Do you want multiple discourse or one that answers to many names?

You can have wordpress pass group information to discourse. It could also do other stuff using api calls.

1 Like

(Jeff Wong) #34

If I’m understanding correctly, your.com is the wordpress site, and he was hoping to have discourse be “the same” domain when users are in the wordpress side, eg your.com/discourse.


(Jay Pfaffman) #35

Then he should search for “subfolder #howto” and and find Subfolder support with Docker

1 Like


So to be clear, your. com/discourse and discourse.your.com are both possible, even when the content of your.com and the Discourse install are running on separate servers?

Between WP and Discourse (or an as-yet-unknown[by me] third option), i don’t know which app should “own” the user accounts and registration process. Any perspective on that?

(OHHHH and i should also mention… i have to somehow connect it all to a Patreon page. :wink:


(Stephen Chung) #37

Usually “Managed” VPS’s mean you don’t have a real VPS because somebody is “managing” it for you. A “real” VPS you need to do all that management yourself.


(Mittineague) #38

Disclosure: I have no personal experience, these are only observations.

Over the last few years I have seen more topics dealing with subfolder problems than subdomain problems here at meta. At least some of the CDCK have advised against it.

The “main” SitePoint site is WordPress, the community is Discourse.

It took some work to get a unified registration / login process in place, but relatively not a long time, and with extremely rare times where “manual” fixes were needed.

The common header took some customized work. But for “branding” it helps a lot.

lMHO, the most work would involve CSS to get both WordPress and a Discourse to not clash, if not similar.

This is true for WordPress and Discourse regardless of setup and depend on your concept of “brand image”.

If the unique difference is between the registration / login process, and subdomain is advised over subfolder I would do that in hopes I had few problems due to my lack of sys op abilities.


(Felix Freiberger) #39

Using a subfolder with Discourse running on a different server is a difficult and somewhat strange setup, I wouldn’t recommend that. (Usually, there is no reason to prefer a subfolder setup anyway.)
Running Discourse on a subdomain (of your usual domain, it doesn’t have to be a different base domain) works fine, independently of whether Discourse is physically running on the same server :slight_smile:


(Jay Pfaffman) #40

Subfolder install needs discourse to be on the same server as the other site.

Which site is the SSO master depends on what you want. Often people use WordPress because it’s already what they are using. Some use discourse because it’s good at social logins.

There is a patreon plugin that will allow patreon to handle logins.


(Jeff Atwood) #41

I improved the error in discourse-setup to reflect what we covered in this topic:

echo “Failed to create swap, sorry!”
echo “Failed to create swap: are you root? Are you running on real hardware, or a fully virtualized server?”


(Michael - DiscourseHosting.com) #42

I think it could be even better if this was not posed as a question, since it is not clear what the desired answer should be (you could read this as “if you’re doing this as root, this will never work”) And the second question looks more like a A or B type of question instead of yes/no.

So how about:

“Failed to create swap. You should be logged in as the root user, and you should be running on real hardware or a fully virtualized server”.


(Jay Pfaffman) #43

There is a check for root at the beginning of the script,so we know that’s not the problem at this point.


(Michael - DiscourseHosting.com) #44

That was not my point. :slight_smile:

1 Like


Heh. Michael’s trying to help you make your error messages less eggheady and more readable/palatable for the everyman :wink: That, or you could go in the opposite direction and call it a GURU MEDITATION ERROR 002534x47754647993591.

You guys have said my host is ripping me off, so i’ve been looking around. This Cloud Server Pro product is only 5 bucks cheaper per month, but is it a far better deal? They claim their meets the specs for Discourse:

  • 4 CPU Cores
  • 4GB Memory
  • 50GB SSD Disk Space
  • 150Mbps Network
  • Unlimited Bandwidth¹
  • Managed w/cPanel
    ( a 20$ value! )

A TWENTY DOLLAR VALUE. Did you hear that? And as i mentioned, i need a gui panel, because life is too short to futz with a command line (or opaquely written error messages).

It’s $50/mo (CAD instead of USD, and i’m in Canadialand).

(Also, where is my Thread Derailer badge?)


(Jay Pfaffman) #46

Yeah, I hear Michael. My point is that we already know they’re root, so we can also remove that from the message.

Mostly, I think that if the script fails to create swap there are no words to communicate to a Normal Person just why it failed. Not many folks know just what a “fully virtualized server” is or how to tell whether they have one.

Usually, if you have cpanel, you don’t have full access to root to do stuff like install Docker and swap.

Cpanel doesn’t know how to deal with Discourse, so the likelihood that it will make things much more complicated or simply not work at all is pretty high. If you can manage to get Discourse to work with cpanel, it still won’t keep you from having to log in and do things at the command line when something goes wrong with Discourse.



Ah! Good observation, and one that i missed. i checked with them, and SSH is included. Does that make this a good (and reasonably priced) route?


(Jeff Atwood) #48

That’s not the purpose, the purpose is that when they copy-paste the error people reading it who do have a clue will go “aha! yes! That’s what they did wrong.”


(Matt Palmer) #49

No, but we can (in many cases), and could detect that and bomb out (for instance, if /proc/user_beancounters exists, then the system is OpenVZ/Virtuozzo).

I think the people who do have a clue already know that if you’re running as root, but you can’t enable a swapfile, we know what they did wrong. The purpose of error messages is to avoid the person having to ask the people who do have a clue.