Thanks for your reply. I thought the permission settings for the "data/sugar" folder might be causing the issue. I'll try again when I have some free time.
M1 chip is not a problem as long as you use our published images, it has been compiled and tested against those.
If you're on Docker Desktop, you should be able to open the container sugar-cron and go to Files and browse to /var/www/html/sugar, that's our mounted directory that points to your sugar install in the SugarDockerized data/sugar folder, see it here.
Docker must have access to that data/sugar folder (container to host) for the scripts to update their permissions.
It's good to see the revival of this tool. I am trying to set Sugar v13 but the permission container is exiting with the error message "Permission Denied" while running the fix permission script. Is it something known and encountered by someone else? I am running it on a Mac with an M1 chip.
I tried a couple of things, but the problem remains, and the installation never went through smoothly. Any ideas here?
great insights Enrico Simonetti , no one better than the creator to explain design decisions.
On toothpaste: I did have some of the engineering team to look into toothpaste but none of us could figure out what the issue was in a timely manner.
I spent a few days trying different approaches but had no luck, so I had to come up with something simpler going forward.
I'm trusting the community to help us figure it out.
Collation Problems: I'd need a bit more details (or your specific instance) to take a look. I did test about 8 different SugarCloud instances before I released the latest versions and I had no problem, so please send me an email with more details (developer@sugarcrm.com) so I can have support/engineering to look into it.
Conflicts on SugarDockerized releases: Please do fix and improve as much as you want, we will sync our fork with your changes, if there are conflicts we need to decide as they come.
A blast from the past! Glad to see that more than a year after not being at Sugar, the tools I've built are still highly used!
A great tool and a real legacy! And good job on maintaining it. Thanks also for the kudos received from the Q&A chat session, whoever you are, I appreciated it!
I am also open to ad-hoc basis consulting, to help out/explain if needed.
I have a few comments regarding specific topics below:
Slowness on Mac: The reason why the system is slow, is the way Mac deals with bind mounts on Docker, hence why the recommendation is a linux VM (or a linux machine) which makes it more than 150 times faster! (You can see empirical tests here: https://github.com/esimonetti/SugarDockerized#disk-performance-stats). See also the official ticket stuck from 2019, perhaps there is no easy solution because of Docker/Mac specific challenges: https://github.com/docker/for-mac/issues/3677
By the way, is there any chance that the team could figure out why toothpaste (used in this project) no longer works on the latest versions of Sugar? Something has changed in the framework that prevents that useful tool from running. It would be great for the community to fix it! By fixing it, you would also no longer require the new repair that you created, as that repair was pretty sweet, doing prewarm and all that as well.
Multiple instances/copying files: The reason why SugarDockerized was born with one instance in mind are multiple:
PHP opcache required an opcache ignore file with full paths (not sure if that's still a requirement today), so having multiple subdirectories or different paths will cause problems as some of the php files cannot be cached or Sugar will not work correctly - https://github.com/esimonetti/SugarDockerized/blob/master/images/php/74/apache/config/php/opcache-blacklist The alternative is to disable opcache all together, making the system slower, and also no longer providing an example of a potential production opcache configuration
As multiple containers use the same files (permissions cron/cli and web) there has to be a way for the system to know where Sugar files are located. Creating a separate volume as an alternative would have similar if not worse challenges, as you would have to copy the files and then have challenges accessing them from outside Docker
There should be a known path to work from, to make all the scripts work (stack, backup, restore, cli, cron etc) that simplifies the use of this relatively complex project. Scripts could be improved to provide a location, but given the previous limitations, it was not worth my spare time investment in improving this further
That is why the backup/restore (github.com/.../SugarDockerized) approach has been provided via the provided scripts, which works as well, as long as the file system interaction for small files is fast enough (e.g.: uses Linux)
Collation problems: I agree with one of the questions. There is a problem with collation. I've restored a customer system and that happened to me as well. I believe with the newest MySQL the default collation is incorrect, plus there is something funky going on, on some of the SugarCloud instances. I had to fix that up manually so that it could work in my case. Perhaps worth a look at Sugar Cloud, and at the default collation of the latest MySQL stacks.
Conflicts on SugarDockerized releases: What happens if I need to release a new version to fix some problems I run into when working with customers, which differs from Sugar's?
Top Comments