Starting points: (RE)Learning Linux commands
-
should read:
./ManageEngine_ServiceDesk_Plus_64bit.binYou may also have to do chmod +x filename.
-
@g.jacobse said:
@scottalanmiller
Not sure why that quoted three time...I feel I hear Foghorn Leghorn's voice here... "No no no son,.. your don't it all wrong..."
You are attempting to use a relative path, but the file is not in your path so it can't find it.
-
@scottalanmiller said:
First thing to do with any CentOS...
yum -y install epel-releaseI completely disagree with this statement because it implies that the EPEL is required. Most of my servers are CentOS 7 minimal and do not have EPEL.
There is NEVER a reason to always add stuff. There are often good reason for most servers, but there is never ALWAYS a reason.
In fact Scott, this is completely contrary to your constant preaching that people should always do things because they are needed and not because they just should because some random internet person said so.f
-
I would make sure you install NTP as well for server, with VMs this becomes even more important.
-
@JaredBusch said:
@scottalanmiller said:
First thing to do with any CentOS...
yum -y install epel-releaseI completely disagree with this statement because it implies that the EPEL is required. Most of my servers are CentOS 7 minimal and do not have EPEL.
It's because of fail2ban being the next recommendation. It's for security reasons.
-
@scottalanmiller said:
It's because of fail2ban being the next recommendation. It's for security reasons.
This is a rationalization that again does not take everything into consideration.
Example: There is no reason to deal with Fail2Ban on an internal device with no public facing ports. In an enterprise setting, maybe, but not in an SMB.
As I said, there is often a reason, but not always..
-
@JaredBusch said:
@scottalanmiller said:
It's because of fail2ban being the next recommendation. It's for security reasons.
This is a rationalization that again does not take everything into consideration.
Example: There is no reason to deal with Fail2Ban on an internal device with no public facing ports. In an enterprise setting, maybe, but not in an SMB.
As I said, there is often a reason, but not always..
@JaredBusch said:
@scottalanmiller said:
It's because of fail2ban being the next recommendation. It's for security reasons.
This is a rationalization that again does not take everything into consideration.
Example: There is no reason to deal with Fail2Ban on an internal device with no public facing ports. In an enterprise setting, maybe, but not in an SMB.
As I said, there is often a reason, but not always..
Nothing is always, of course, but for someone new to Linux, I would "always" do it until you are comfortable with not needing to ask them question then decide for yourself. If you need to ask... install it.
But even for internal systems with no external ports I want fail2ban. It helps protect against internal breaches too.
-
@scottalanmiller said:
Nothing is always, of course, but for someone new to Linux, I would "always" do it until you are comfortable with not needing to ask them question then decide for yourself. If you need to ask... install it.
I am not arguing that Fail2Ban is bad, I am arguing that you are setting standards that you tyhing are simple when they are not.
The problem here is that you are adding complexity.
The new user now also needs to deal with learning how to properly configure Fail2Ban. An out of the box CentOS7 install is fairly secure to begin with. You have to open up most ports with a firewall-cmd in the first place..
@scottalanmiller said:
But even for internal systems with no external ports I want fail2ban. It helps protect against internal breaches too.
This is complete overkill in the SMB.
-
@JaredBusch said:
The problem here is that you are adding complexity.
The new user now also needs to deal with learning how to properly configure Fail2Ban. An out of the box CentOS7 install is fairly secure to begin with. You have to open up most ports with a firewall-cmd in the first place..
This is complete overkill in the SMB.I don't agree, the root user on a default install is pounded on relentlessly if exposed. Fail2Ban adds nominal complexity but a significant amount of protection. And other than turning it on, no configuration needed for the most important role (protecting SSH.) I'm actually very disappointed that RHEL doesn't make it part of their minimum install.
-
@scottalanmiller said:
I don't agree, the root user on a default install is pounded on relentlessly if exposed. Fail2Ban adds nominal complexity but a significant amount of protection. And other than turning it on, no configuration needed for the most important role (protecting SSH.) I'm actually very disappointed that RHEL doesn't make it part of their minimum install.
Your disappointment does not alter the fact. that again, for an internal server it is a complete waste of time.
This is my entire point. You are assuming public facing service always.
-
No matter how small you are, Fail2Ban is an effort only on a system by system basis (so the effort scales as your deployments do) and offers serious protection levels lacking in the base install. It is far easier to configure Fail2Ban than to disable password-based access to a system.
