It was about six weeks ago last time I tried it, but I believe it was just the entire frappe-bench directory. There were a few extra steps, like relinking nginx.conf, but all pretty straightforward as I recall.
So did you have to install python, nginx and mariadb before you unzipped the tarball or were you restoring the tarball to a server that had already once been an erpnext server?
BKM
It was a clean server, and then I installed frappeās dependencies like normal. I canāt recall my steps exactly, but I suspect you could just follow the standard manual installation instructions and then just stop at the bench new-site command. Iām happy to discuss more, but itās probably worth doing it in a new thread. Feel free pull me in if you start one.
1 Like
ERPNext is not a desktop application. It is an enterprise ERP system, which has many moving parts which work together.
From what I gather, you are installing ERPNext on behalf of your client. It would then be expected of you to manage the change.
A good change control process will document
=> pre-conditions and pre-requisites
=> the upgrade process
=> backup and recovery process
=> back out process
You cannot expect to cut and paste commands and hope it works. Often for production software, a beta system is required. You would be expected for major changes at least to perform the upgrade on a beta system. We are a small manufacturer and have both a beta system and production system. Because we understand the value of constant updates and the nature of the ERPNext system releases, we see it fit to manage upgrades in this way.
3 Likes
Have a look here.
This helped me to get going. There may have been some minor changes here and there from the docs, but it was a good starting point.
Exactly! I do this with clients already. The problem is how to save them in the event of a server failure. I already have methods in place to make frequent backups of the databases and supporting files.
The problem is being able to replace the installed program with the exact same version the users were running before the failure. THIS is where I find the difficulty.
The only successful approach I have found is to have a complete image backup that I can have restored to a brand new server when there is a failure. This is because there is actually no effective way to re-install ERPNext to a point version that the users were on before the failure event.
Someone here suggested making a tarball from the frappe-bench bench directory and unzipping it to a new server then restoring the database and the support files. However, when I tried this in the past I could not get the server to work. Important pieces are not residing in the frapp-bench directory like the mariadb programs, and nginx, etc. Hopefully someone that has been successful with the tarball approach can elaborate a little on how to get it working.
However, up to this point I have not heard of anyone that can for example install a v10.0.14 version of ERPNExt on a fresh server and then restore their backups. For that matter it is not reliable to try to install the last supported version of v10 and expect that it will be identical to the same installation a week later due to the constant changes happening in all of the supporting packages.
This is why I compared it to NOT being like a MS Windows package. I have installed many MS Windows Server 2016 packages where everything is built into the cab files that are used to do the install. Doing it this way gives you the exact same install every time not matter if it is this week, next week, or next year, the server will just work! So no I am not comparing some simple desktop install to a server install.
Exactly again!!
I take it a step further and freeze the production server at whatever point revision it is when it goes live and I do NOT allow any updates for 2 to 3 years. I provide a live production server, a āsandboxā server for users to practice how they use the system, and 1 or 2 hot spare servers that are automatically updated every hour with fresh database and support file backups.
In this case I do not need a ābetaā server because I do not allow upgrades anyway. All I care about is being able to replace any one of the servers with a fresh one in the event there is a hardware failure at the server farm. THIS is all I am referring to when I decry the inability to make a fresh copy of an older server (even if it is supposedly still a supported version).
Currently I have one configuration where the primary live production server is in New York. The same day I created it, I also took an image backup of it and restored it to identical servers in New Jersey, Chicago, and Los Angeles. This gave me a production server and 3 possible hot spare backups. One day last year the primary live production server in New York failed and all information was lost and unrecoverable. No problem, I just switched the users to the New Jersey server and kept on going.
The problem came around when I tried to replace the bad New York server with another one configured exactly the same way. Since the time I created the original servers the VPS service provider changed their standard configuration to include a little more memory and a little less disk space but moved to SSD drives. Now my image backup will not restore to the servers of the new configuration due to the disk size differences and I have no way to get back a replacement server for the dead one. The great techs at the service provider tried everything they could think of and could not get a restore process to work.
Now the question is how do I re-create another server with the exact same version of the software? So far, I cannot. This is the problem I have been search an answer for and not whatever everyone else has been reading into my posts.
I am happy that you find value in the constant updates to ERPNext. Your experience is exactly the opposite of mine in this respect. I have not found a single user base that was comfortable with interrupting their users to teach them new ways they might have to use their software each time it changes. Changes to them cause work slow downs and impede their revenue flow. This is why they all choose to have wither 2 year freezes or 3 year freezes on version changes when they sign with me. Almost all of them have had the terrible experience of upgrading versions frequently of other software and specifically want a guarantee that they will be protected from that situation for a fixed period of time.
BKM
2 Likes
Thank you for the link. I will try to digest this over the coming weekend and see if I can get your tarball approach to work.
BKM
Thank you!! 
I will do some experimenting with this and may setup another thread is I get stuck. I have a rainy weekend ahead to sit at the terminal and work on this.
BKM
And this is why docker images are so useful! They work so far in docker compose environment (last I remember) but Iām actively (well, I had to take a break because of school, but Iāll be on it from the beginning of next week) working on getting docker swarm to work with it so hopefully weāll see results soon.
I guess more control of that sort only comes with more contributions into the core code (which I admit is a bit of a chicken-and-egg sort of situation). Also the way the maintenance is structured currently you could not really say even whether there would be any automatism in such an equation. The maintainers (I believe 100% Frappe PvT employees [correct me whether I am wrong in this please]) have a focus on what is best for the erpnext.com product. Naturally this may not automatically be best for anybody else.
2 Likes
I agree with your proposal, ERPNext needs to continue improving,
Moving on for Desk 2.0. I reviewed a new V12 install and I keep myself for a while for the lost desktop icons. Seeing the modules group together, I now understand the changes well. I am writing a separate thread what could be a simple possibility to reintegrate those eye candy.
Is this a manifestation of the aggressive update mindset for the ERPNext team? Should anyone be relieved from the pressure of being backward compatible? Even testing considering different countries?
A proper use of OO Design Patterns should cure the problem all together. Rather than an aggressive update strategy, Factory Patterns may be able to provide the same functions/classes/services to all versions via a simple check.
1 Like
I hear your frustration. I also understand the core teams need to simplify support in their future by having to maintain only one user interface, testing of new application paths, etc.
I also understand their desire to advance their āproductā to wider audiences with their additions to the application.
I just believe they have created giant Jenga puzzle that they are having a hard time managing at itās current height. Every new update threatens to collapse the whole tower.
I donāt believe they have the stomach to redesign the core of the product to make itās growth more manageable. It would set them back at least a year. Yet, all of the version updates are now taking almost as long just to stabilize enough for users to accept them as useful.
I fear that the current incarnation of the product might be abandoned by the core developers in the not to distant future simply due to the complexity of adding anything more to it and the diminishing returns for the effort expended.
Just my thoughtsā¦
BKM
3 Likes
I will beg to differ here as it is not frustration, plain OO design. I think that stage in this project provides us a very good opportunity to convert lessons learned to action and principles.
The product is still solid and promising, I guess the development could not handle the peak demand which I donāt think most of them are informed requests. Confronting them with ignorant developers produced a few catastrophes but still we are in a manageable state.
Why is it not possible to use git to start again at a particular release or commit? Iāve been doing that for years now, and it works fine, even sets up dependencies as they were at the time.
You really need to learn version control if you think the latest release is the only release.
Now that is funny.
I never believed that the latest version was the only version available. However, until very recently it was not really possible (using the easy install method) to install anything but the latest production version.
Even funnierā¦ even trying to get the latest version to install via the easy install method you will find yourself having to stand on one foot, squint your eyes, and pray to get what should be a simple install to work.
Soā¦ there are many of us that do not know as much as yourself about how to manipulate the manual install process to possibly achieve installing a specific point version. Last year I was trying to find ANYONE that vould help me install a fresh copy of 10.0.14 on a fresh Ubuntu server.
You know what I found?
Even after paying a developer to try to accomplish this, it could not be done.
So, If you can prove to me that you can install v10.0.14 on a fresh Ubuntu server I will change my tune (since that is what I was trying to do at the time of this original post). Until that time you are just spouting opinions.
BKM
Additionallyā¦ the intent of my old comments was to shine a light on the fact that the install.py and the playbooks do NOT in fact have any semblance of control over the versions of the packages that are also install as support to ERPNExt/Frappe.
They only take whatever is the most recent release of whatever tool they are attempting to use. This makes it possible for you to install a fresh erpnext server at 10am and then 2 hours later install another fresh erpnext server and they would still be different because the authors of pip, or mariadb or any other package have changed their own releases.
The playbooks (for the most part) do NOT specify the versions of many of the installed packages.
BKM
1 Like
January 2020: ERPNext still remains completely NonDeterministic.
Most users have zero control over:
- Frappe app target commit
- ERPNext app target commit
- Version of PyPi dependencies downloaded.
- Version of NodeJS dependencies downloaded.
Even worse, the default option during installation is adding ābench updateā to an automatic cron job. So that day-to-day, you donāt even know what code is running. If a bad pull request makes its way into version-12? Youāre stuck with it, until a maintainer fixes the problem.
Yes. There are a few individuals who have sufficient mastery of Linux, Python, Node, SQL, and Git. Enabling them to fully control their environments, and freedom to hack their way through any inconveniences.
Those individuals are the rare exception.
For everyone else, they wonder why ERPNext installation is awful. Or why ERPNext configuration and setup is a mystery. Or why most Production Environment designs are undocumented, tribal knowledge.
I got fed up last year, and kicked off my Weavlo project. So that people can actually successfully install ERPNext with not only consistency, but with Deterministic results. Iām still actively working on that; Iām pleased where itās headed. Still, itās a huge endeavor to make a One-Size-Fits-All installer. My clientsā work and businessā work takes first priority. So progress has been slow.
In the meantime, no matter how loud ERPNext is touted as āa replacement for SAPā, that is hardly the truth. Itās a product with great potential. But was designed by Python and JavaScript programmers for Python and JavaScript programmers.
For everyone else, you muddle your way through it, and deal with the instability. Or you eventually give up and use another product.
11 Likes
I couldnāt agree more.
It appears the only āeasyā way to get ERPNext is to:
Subscribe to the paid cloud service, erpnext.com
Hire someone to install it for you.
Became a developer/Learn the skills to install it your self
Is this the business model for ERPNext?
1 Like