HelpDesk Options
-
@scottalanmiller said in HelpDesk Options:
@G-I-Jones said in HelpDesk Options:
@scottalanmiller said in HelpDesk Options:
@G-I-Jones said in HelpDesk Options:
@scottalanmiller said in HelpDesk Options:
@G-I-Jones said in HelpDesk Options:
Source: All command line?
I don't understand this one. All scripts are source. No matter how you run Zammad, it is source. There is only the source code, that's the entire application.
It was phrased as a question because I didn't understand it.
I'm not sure what the question was, though
What does the option mean on zammad.org?
I was just looking around their site to see if I could figure out what prompted you to ask about that word.
Zammad is using the term 100% wrong here and it is gibberish. What they mean is installing from a tarball (tarball is a specific type of compressed file like a zip file, but common everywhere outside of Windows) versus installing from a repo. Whoever wrote that part of their documentation is completely confused and doesn't know what they are writing.
Zammad is a Ruby on Rails application and as such, is a script, and as such is always source.
Source is short for source code and always means the code of the application, there is no exception. Every install method that they offer (or could offer) is equally source. The one that they call source is no more or less than any other. It's easy to tell how they got confused, it's a non-developer who saw some of these things in a different situation, totally misunderstood what they saw, and repeated it wrong when writing this doc. I could make a video just explaining that, lol.
But it is always source, and the term is completely misused. That's all that you need to know.
Ah, see, I thought "maybe they mean Source Code" but in all honesty that wouldn't have gotten me much further. You're explanation is both needed and appreciated.
-
On CentOS the install looks to be this easy, just run these three commands as root...
yum -y install epel-release wget wget -O /etc/yum.repos.d/zammad.repo https://dl.packager.io/srv/zammad/zammad/stable/installer/el/7.repo yum -y install zammad
-
@G-I-Jones said in HelpDesk Options:
Ah, see, I thought "maybe they mean Source Code" but in all honesty that wouldn't have gotten me much further. You're explanation is both needed and appreciated.
They meant source code, but whoever wrote it doesn't know what source code is and it makes no sense.
What they should have said is...
Install from TarBall without a Repo
Or CentOS via RPM, Ubuntu via DEB, etc.
-
They meant source code, but whoever wrote it doesn't know what source code is and it makes no sense.
What they should have said is...
Install from TarBall without a Repo
Or CentOS via RPM, Ubuntu via DEB, etc.
Gotcha. Thanks, I'm almost a pro at this already.
-
-
@G-I-Jones said in HelpDesk Options:
They meant source code, but whoever wrote it doesn't know what source code is and it makes no sense.
What they should have said is...
Install from TarBall without a Repo
Or CentOS via RPM, Ubuntu via DEB, etc.
Gotcha. Thanks, I'm almost a pro at this already.
https://republicofit.com/topic/7825/sam-learning-linux-system-administration
-
I would definitely install Zammad via repo instead of docker.
There docker image is a single container based application designed to have Zammad up and running fast for testing purposes.
https://docs.zammad.org/en/latest/contributing/install-docker.html#install-with-docker -
For testing purposes, it was pretty easy to setup Zammad via docker using podman on Fedora 31.
sudo sysctl -w vm.max_map_count=262144 sudo podman container run -ti --rm --name zammad -p 80:80 zammad/zammad
-
@black3dynamite said in HelpDesk Options:
For testing purposes, it was pretty easy to setup Zammad via docker using podman on Fedora 31.
sudo sysctl -w vm.max_map_count=262144 sudo podman container run -ti --rm --name zammad -p 80:80 zammad/zammad
Yeah I pretty much default to Podman for 99% of the stuff I'm testing. Or if I "need" a VM I'll use Vagrant.
But Podman might be a little much for this conversation.
-
-
To come back around to the initial question, I'll throw GLPI + FusionInventory into the mix as a decent replacement for SpiceWorks. You keep the ability to have your whole IT environment managed and documented in a single system (Equipment, users, ticketing, contracts, contacts etc etc....)
-