ERPNext in 2014 and in 2016

Dear All,

I installed ERPNext during its early days in 2014 on a multi-purpose FreeBSD server with a number of jails for each service and security features to match its exposure to the open internet. It was not easy, but doable, and I recorded every step for easy reference.
Two years later, I tried it again. The set up process seems to be more automated, has done away with some complex broker mechanisms and opted for the easier-to-deploy Redis. Huge changes have been made in the overall process and architecture.
There are two issues that come out of the above positive developments that worry me: First, how can I, as a user, upgrade and migrate my data smoothly from on older version to a new one, if the architecture got so much changed?
Second: The “easy installation process” is OK for dedicated machines, but sheer hell for multi-purpose servers. Nowadays, ports are hard-coded, and configuration files are all over the place. Some settings can be changed via command-line functions via frappe-bench. But overall thre impression remains that this is now a user-friendly application, that is fiendishly difficult to integrate into any standard environment with existing database, Redis, reverse proxy and memcached servers on DIFFERENT servers with ports that may not tally with the default ones coming with ERPNext.
This development towards “facilitated complexity” is regrettably. Why no going the KISS way and employing simple configuration file, where everything can be set and changed? Or, if you like, use buildout?
I may have to let ERPNext drop - the installation process is scary, and what us even more scary is the prospect of getting caught in an insurmountable upgrade task some time later.
Sadly so, admittedly. Any advice will be highly appreciated.

Chris

Chek this:

We are moving the installation to Ansible, exactly for the reasons you mention. Its WIP, but usable:

Thanks a lot for your reply. Upgrades are sorted then. Great.
As for Ansible, this is actually exactly the direction I do NOT prefer. It is quite easy to create a complete virtual environment to run an application server, with broker, database, cache and what-not server instances thrown in. But: This is also tremendously wasteful, because in most production environments we already have a, say, database server, a reverse proxy server, a Redis server, a memcached server, etc. So why replicate these efforts and use valuable system resources, duplicate maintenance efforts, etc.?
Don’t misunderstand me: I love ERPNext for its usability. But I simply won’t deploy it, unless it can, via clear and simple configuration settings, use EXISTING, NON-LOCAL services. We had this issue with MySQL/MariaDB before - this got sorted. It was NOT an issue pre-5 with broker services, but now qwe need TWO (!) LOCAL Redis instances, while my powerful external Redis server (with password and several databases at hand) could have these tasks thrown at. This simoly does not make sense, sorry.
Also, the SocketIO requirement is all fne and dandy, if we could fix the port. Port 3000 going to an external reverse proxy (Nginx, NOT-LOCAL!) is identical to Ruby on Rail’s standard app port. While I can change the hard-coded settings in socketio.js, I am not entirely sure about itsw implications, and things should be done transparently via a simple config file. (Of course a common config and per-site configs are fine.)
Thoughts?
Chris

Ideally, redis connections strings (for cache, broker, async result) should be configurable with a connection string (redis://hostname/dbname). It is recommended to use multiple instances of redis than multiple databases in the same redis instance. Also, we run the cache redis in a LRU mode (different config from broker).

The socketio port is also configurable, https://github.com/frappe/frappe/blob/develop/socketio.js#L256

– just scrolled up and read that you want to run everything in different jails, perfectly valid requirement :smile:. A nicely written ansible playbook would have roles and you’d run different roles on different jails and still should end up with a working system (in which you don’t throw everything in single system).

The redis for async and socket.io need to be configured in frappe-bench/config.json, keys being redis_async_broker_port and socketio_port

and the celery broker, async broker (again!) and cache server need to be configured in frappe-bench/sites/common_site_config.json, keys being celery_broker, async_redis_server and cache_redis_server

I agree all this config should be from common_site_config.json and in dbstring like format.

1 Like

Thanks a lot, indeed, for this.
It is good to see that the sockert.io port can be set. Yes, Redis connection strings would be terrific, but should include the redis password stiff to, as in "redis://:[redes password]@[redis_server]:[redis_port]/[redis_database_number]. With this, I could run several Redis instances on my Redis server, and all is set.
The same probably applies to the celery broker service.
Maybe in one of the next versions? Let me try to get thi up and running first, suqeezing things into my jail structure.
Cheers from Vietnam,
Chris

Dear All,

I can confirm that the suggested stanzas in frappe-bench/config.json do NOT work. Specifically, redis_async_broker_port and socketio_port, even if set, have no influence on the running of ERPNext whatsoever. :frowning:

Any ideas? Thanks a lot.

Chris

That is weird. Not sure why changing these settings has had no effect. I haven’t had the need for what you are trying to do but would expect it to work. Will watch thread. Good luck.

You will have to regenerate the various redis config after changing the ports in config.json

Thanks a lot, Anand. Quite obviously, there is a lot to learn about the Frappé framework.
Two questions: Is it possible to transmit a Redis password to an external Redis server that I could use as broker instead of the local one? (This would do away with one unnecessary local duplication of services :slight_smile: !)
Also, can I server ERPNext from a sub-URI? This would reduce costs for a wildcard or multi-domain certificate.
Any thoughts and hints? Hugely appreciated. Once done, I will send you FreeBSD installation instructions for your peruse. Phew.
Bests from Vietnam,
Chris

Dear All,

While I got ERPNext going with Redis & friends running on localhost, there are still a few remaining issues that need clarification, please:

(1) socket.io. From our previous correspondence, I can set the preferred port in frappe-bench/config.json, e.g.:
socketio_port": “3001”.
Alas, this does not work, even after running bench “setup socketio” . Likewise, I fail to see where I could set a host address to bind to.

(2) In frappe-bench/sites/common_site_config.json, I am supposed to be able to set celery_broker, async_redis_server and cache_redis_server. I tried to look for the complete *config.json documentation, but the GitHub link does not work, hence my questions:
I set, for instance:
“celery_broker”: " “celery_broker”: “redis://:[redis password]@broker.jail.vlan:6379/1”,
“async_redis_server”: “redis://:[redis password]@broker.jail.vlan:6379/1”,
“cache_redis_server”: “redis://:[redis password]@broker.jail.vlan:6379/2”
This seems to work and to connect to my external Redis server. Did I get it right that the celery broker is supposed to connect to the async_redis_server (broker), hence same connection details?
This leave the cache_redis_server running locally.

(3) I am supposed to be able to set redis_async_broker_port in frappe-bench/config.json. As with socket.io, this won’t float, even after running “bench setup redisa_async_broker” and “bench setu redis_cache” for completeness. Therefore, I get SocketIO errors in my log, as SocketIO cannot connect to localhost:12311… whatever is set in frappe-config/config/redis_async_broker.conf.

Any ideas, what I might have missed?
Thanks a lot, indeed.

Chris

Addendum: Socket.IO seems to be unable to connect to a Redis broker service that requires passwords. The redis:// connection strings in common_site_config.json do not do anything to change that. :frowning:
Hence, even NATing of remote Redis ports to local ports won’t do the trick.
Hmmm…
Chris

Hi,

Use “cache_redis_server”: "redis://[:password]@localhost:[ redis://[:password]@localhost:[port]” in common_site_config.json. Similarly, do it for keys “async_redis_server”, “celery_broker”.
You can set “dns_multitenant” in frappe-bench/config.json, name your site folders as subdomain.example.com http://subdomain.example.com/, and run bench setup nginx to generate a new config.

Best,
Anand Doshi

ERPNext

Dear Anand,

Did this - and for the Redis instances, the “redis://…” strings for the “cache_redis_server”, “async_redis_server” “celery_broker” keys do work. I figured that the databases for “async_redis_server” and “celery_broker” have to be identical - hope this is correct.
The issue is, I think, ScketIO’s reluctance to take on any configuration - see above. It insists on password-less connection to Redis (which I cannot live with) and does so on localhost with port 12311 (which I can live with, using NAT). For details, kindly see above messages.
Any thoughts? Thanks a lot!
Chris