linux命令出错 linux查看报错命令

linux管理常见错误,该如何解决?

linux管理常见错误一:随意许可,原因是不理解许可

创新互联专注于南宁企业网站建设,成都响应式网站建设公司,商城网站定制开发。南宁网站建设公司,为南宁等地区提供建站服务。全流程按需规划网站,专业设计,全程项目跟踪,创新互联专业和态度为您提供的服务

如果对许可配置不当,就会给黑客留下机会。处理许可问题的最简单方法是使用所谓的RWE方法,即Read(读取)、Write(写入)、Execute(执行)。假设你想让一个用户能够读取一个文件但不能写入文件。为此,你可以执行:chmod

u+w,u-rx 文件名,一些新用户可能会看到一个错误,说他们没有使用文件的许可,因此他们就使用了:Chmod 777

文件名,以为这样能够避免问题。但这样做实际上会导致更多的问题,因为它给了文件的可执行的权限。

记住这一点:777将一个文件的读取、写入、执行的许可给了所有用户,666将一个文件的读取、写入权限给了所有用户,而555将文件的读取、执行权限给了所有用户,还有444、333、222、111等等。

linux管理常见错误二:忽视更新

这并不是说Linux管理员缺乏技巧。不过,许多Linux管理员在运行了Linux之后,以为日后就无事可做了,以为它安全可靠。其实,新的更新可以为一些新的漏洞打上补丁。维持更新可以在一个易受损的系统与一个安全的系统之间构造分水岭。Linux的安全来自于不断地维护。为了实现安全性,为了使用一些新的特性和稳定性,任何管理员都应当跟上Linux的更新步伐。

linux管理常见错误三:不经过严格审核,从多种渠道下载安装各种类型的应用程序

乍看起来,这也许是一个不错的主意。如果你在运行Ubuntu,你会知道包管理程序使用的是。deb软件包。不过,你找到的许多应用程序是以源代码的形式提供的。没有问题吗?这些程序安装后也许能够正常工作。但是你为什么不能随意安装程序呢?道理很简单,如果你以源的形式安装了程序,那么,你的软件包管理系统将无法跟踪你所安装的东西。

因此,在程序包A(以源的形式安装)依赖于程序包B(从一个。deb库安装的),而软件包B是从更新管理器更新的时候,会发生什么事情呢?程序包A可能运行,也可能无法运行。不过,如果程序包A和B都从。deb库安装的话,二者都能运行的机会将更高。此外,在所有的程序包都来自于同样的二进制类型时,更新程序包将更为容易。

linux管理常见错误四:将服务器启动进入到X

在一台机器是专用服务器时,你可能会想到安装X,这样一些管理任务就会简单一些。不过,这并不意味着用户需要将服务器启动进入到X.这样会浪费珍贵的内存和CPU资源。相反地,你应当在级别3上停止启动过程,进入命令行模式。这样做不但会将所有的资源留给服务器,而且还会防止泄露机器的机密。要登录到X,用户只需要以命令行方式登录,然后键入startx进入到桌面。

linux管理常见错误五:糟糕的口令

记住,root

的口令通常是linux王国的关键。所以为什么要让root的口令那么容易被破解呢?保障你的用户口令的健壮性至关重要。如果你的口令比较长,且难于记忆,可将这个口令存放在一个可被加密的位置。在需要这个口令时,可用解密软件解开这个口令使用之。

linux管理常见错误六:没有备份关键的配置文件

许多管理员都有这样的体会,在升级到某个X版本,如X11之后,却发现新版本破坏了你的xorg.conf配置文件,以至于你再也无法使用X?建议你在升级X之前,先对以前的/etc/x11/xorg.conf作一个备份,以免升级失败。当然,X的升级程序会设法为用户备份xorg.conf文件,但它却在/etc/x11目录内备份。即使这种备份看起来不错,你最好还是自己做一个备份吧。笔者的一个习惯是将其备份到/root目录中,这样,用户就可以知道只有根(root)用户能够访问此文件。记住,安全第一。这里的方法也适用于其它的关键备份,如Samba、Apache、Mysql等。

linux管理常见错误七:忽视日志文件

/var/log的存在是有理由的。这是存放所有的日志文件的唯一位置。在发生问题时,你首先需要看一下这里。检查安全问题,可看一下/var/log/secure.笔者看的第一个位置是/var/log/messages.这个日志文件保存着所有的一般性错误。在此文件中,你可以得到关于网络、媒体变更等消息。在管理一台机器时,用户可以使用某个第三方的应用程序,如logwatch,这样就可以创建为用户创建基于/var/log文件的各种报告。

linux管理常见错误八:没有安装一个可正常运行的内核

你可能不会在一台机器上安装10个以上的内核。但你需要更新内核,这种更新并没有删除以前的内核。你是怎么做的呢?你一直保持使用最近的可正常工作的内核。假设你目前正常工作的内核是2.6.22,而2.6.20是备份内核。如果你更新到2.6.26,而在新内核中一切都工作正常,你就可以删除2.6.20了。

linux管理常见错误九:逃避使用命令行

恐怕很少有人愿意记住那么多命令。在大多数情况下,图形用户界面是许多人的最爱。不过,有时,命令行使用起来更加容易、快捷、安全、可靠。逃避使用命令行是Linux管理的大忌。管理员至少应当理解命令行是如何工作的,至少还要掌握一些重要的管理命令。

linux管理常见错误十:以根用户身份登录

这是一种很危险的错误。如果用户需要根特权来执行或配置一个应用程序,可以在一个标准的用户账户中使用su切换到root用户。登录到root为什么不是一件好事儿?在用户以标准用户身份登录时,所有正在运行的X应用程序仍拥有仅限于此用户的访问权。如果用户以根用户身份登录,X就拥有了root的许可。这就会导致两个问题,一、如果用户由GUI犯了一个大错,这个错误对系统来说,有可能是一个巨大的灾难。二、以根用户的身份运行X使得系统更易于遭受攻击。

查看linux的启动信息指令错误的是

题主是否想要询问“怎么查看linux的启动信息指令错误”?

1、首先打开电脑,并启动linux。

2、其次打开linux的自检功能。

3、最后等待自检解释即可得知linux的启动信息指令错误。

Linux 出现command not found 错误解决

在很多人学习Linux命令行,会经常遇到command not found 错误,出现上述错误主要有以下几种情况:

命令书写错误,如有些人将Windows命令与Linux命令搞错,如查看ip相关信息,Linux命令行应该为ifconfig

环境变量没有配置好,这里一般有两种解决方法,第一,可以切换到root用户执行命令,第二种,就是配置用户的环境变量,其指令如下:

export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

----------------------------分割线----------------------------

Linux命令找不到?(找不到命令)

这个问题其实很简单,如果你在终端输入一个命令,而系统提示你说命令没有找到(Command not found)的话,要么是因为你没有装相应的软件包,要么就是因为路径设置的问题。如果是因为软件包的问题,那没有别的好说的,安装相应的软件包就好了。而另外一种情况,则需要对用户的路径进行设置。这里针对普通用户和超级用户分开介绍,以 RedHat 些列为例。

一、普通用乎如果一些程序没有安装在系统默认的路径(ie /bin/, /usr/bin, /usr/local/bin/ )里面,这个时候普通用户想要调用这些命令,必须设定路径。方法很简单:以普通用户登录,然后在终端输入:

vi ~/.bash_profile

会出现如下的内容:# .bash_profile

export PATH此时,只要在export PATH前面加入自己的路径即可,例如我的修改后如下:[ @localhost bin]$ cat ~/.bash_profile# .bash_profile# Get the aliases and functionsif [ -f ~/.bashrc ]; then . ~/.bashrcfi# User specific environment and startup programsPATH=$PATH:/usr/local/programs/crosstool/gcc-4.0.2-glibc-2.3.6/arm-linux-gnu/bin/export PATH

二、超级用户这里主要是一些用在系统管理上的命令,例如ifconfig, route等等, 他们位于/sbin, 或/usr/sbin/下。其实这些命令本身就没有任何问题,软件包早已安装完毕,路径设置也没有丝毫问题。而出现Command not found的原因在于:在终端使用su变成超级用户的时候没有将root的路径(环境)一起切换过来,从而导致身份虽然已经是root,但是工作的环境和路径依旧是普通用户的。这种问题的解决方法有两个,其一是按照(一)里面提到的,对普通用户的工作路径进行修改,但是这样比较麻烦。其二则简单的多,只要在使用su的时候在其后家上一个空格和”-“ ,即将su改为 su - 。这样就可以在成为root的同时将root的工作路径也一起切换过来了。如果你已经使用su变成了root,那也没有关系,只要在输入一下su - 就好了。

原文地址:


本文名称:linux命令出错 linux查看报错命令
标题来源:http://azwzsj.com/article/hgipdi.html