CentOS5.3 last信息有一条自动重启服务器的信息,但是并没有用户执行过重启命令,messages dmesg 日志都没发现有用信息,初步怀疑机房电源问题。
2011-06-08
发表者 Venus
暂无评论
2011-06-08
发表者 Venus
暂无评论
CentOS5.3 last信息有一条自动重启服务器的信息,但是并没有用户执行过重启命令,messages dmesg 日志都没发现有用信息,初步怀疑机房电源问题。
2011-06-07
发表者 Venus
暂无评论
目前Red Hat推荐交换分区的大小应当与系统物理内存的大小保持线性比例关系。不过在小于2GB物理内存的系统中,交换分区大小应该设置为内存大小的两倍,如果内存大小多于2GB,交换分区大小应该是物理内存大小加上2GB。其原因在于,系统中的物理内存越大, 对于内存的负荷可能也越大。
但是,如果物理内存大小扩展到数百GB,这样做就没什么意义了。
实际上,系统中交换分区的大小并不取决于物理内存的量,而是取决于系统中内存的负荷。Red Hat Enterprise Linux 5可以在这样的情况下工作:完全没有交换分区,而且系统中匿名内存页和共享内存页小于3/4的物理内存量。在这种情况下,系统会将匿名内存页和共享内存页锁定在物理内存中,而使用剩余的物理内存来缓冲文件系统数据(pagecache),当内存耗尽时, 系统内核只会回收利用这些pagecache内存。
考虑到以下情况:
1)安装系统时难以确定内存的负荷,如何设置交换分区大小
2)系统中物理内存越大,所需交换分区就会越少
因此,在Red Hat Enterprise Linux 5中,以下是设置合适的交换分区大小的规则:
•小于等于4G物理内存的系统,至少设置2GB的交换分区
•4G~16G物理内存的系统,至少设置4GB的交换分区
•16G~64G物理内存的系统,至少设置8GB的交换分区
•64G~256G物理内存的系统,至少设置16GB的交换分区
2011-06-02
发表者 Venus
暂无评论
所谓的“实例”,就是一个 SQL Server 数据库引擎。 SQL Server支持在同一台计算机上同时运行多个 SQL Server 数据库引擎实例。每个 SQL Server 数据库引擎实例各有一套不为其他实例共享的系统及用户数据库。应用程序连接同一台计算机上的 SQL Server 数据库引擎实例的方式与连接其他计算机上运行的 SQL Server 数据库引擎的方式基本相同。由于实例各有一套不为其他实例共享的系统及用户数据库,所以各实例的运行是独立的,一个实例的运行不会受其他实例运行的影响,也不会影响其他实例的运行。在一台计算机上安装多个 SQL Server 实例,就相当于把这台计算机模拟成多个数据库服务器,而且这些模拟的数据库服务器是独立且同时运行的。
实例包括默认实例和命名实例两种。一台计算机上最多只有一个默认实例,也可以没有默认实例,默认实例名与计算机名相同,修改计算机名会同步修改默认实例名( SQL Server 7.0 只能被安装为默认实例,在修改计算机名后,会导致 SQL Server 服务无法启动,需要执行 SQL Server 安装程序进行自动修复才能解决启动问题),客户端连接默认实例时,将使用安装 SQL Server 实例的计算机名。
一台计算机上可以安装多个命名实例,客户端连接命名实例时,必须使用以下计算机名称与命名实例的实例名组合的格式:
Computer_name\instance_name
实例主要应用于数据库引擎及其支持组件,而不应用于客户端工具。如果安装了多个实例,则每个实例都将获得各自唯一的一套:
系统和用户数据库。
SQL Server 和 SQL Server 代理服务。对于默认实例,服务名仍为 MSSQLServer 和 SQLServerAgent。对于命名实例,服务名改为 MSSQL$instancename和 SQLAgent$instancename,使得这些服务与服务器上的其它实例分开启动和停止。可使用相关联的 SQL Server 服务启动和停止不同实例的数据库引擎。SQL Server 代理服务管理相关联的数据库引擎实例的调度事件。 与数据库引擎、SQL Server 和 SQL Server 代理服务相关联的注册表键。
使应用程序能连接特定实例的网络连接地址。
2011-06-02
发表者 Venus
暂无评论
SQL Server2008R2 ,打开Management Studio时,采用windows身份验证,登陆失败:
查看系统日志:
用户 ‘SRV08\Administrator’ 登录失败。 原因: 基于令牌的服务器访问验证失败,出现基础结构错误。请检查以前的错误。 [客户端: <local machine>]
最后确定错误出在安装的时候,为数据库引擎指定身份验证模式和管理员,我选择了”网络服务”账户,结果当前系统登陆为administrator,SQL Server就采用administrator登陆数据库,但是当前账户并不是数据库管理员,所以失败。”网络服务”账户也不能登陆系统(系统账号不能登陆系统),没别的好办法,只好重装数据库。注意以下两部分:
2011-06-02
发表者 Venus
暂无评论
1. 包过滤技术
包过滤是最早使用的一种防火墙技术,它的第一代模型是“静态包过滤”(Static Packet Filtering),使用包过滤技术的防火墙通常工作在OSI模型中的网络层(Network Layer)上,后来发展更新的“动态包过滤”(Dynamic Packet Filtering)增加了传输层(Transport Layer),简而言之,包过滤技术工作的地方就是各种基于TCP/IP协议的数据报文进出的通道,它把这两层作为数据监控的对象,对每个数据包的头部、协议、地址、端口、类型等信息进行分析,并与预先设定好的防火墙过滤规则(Filtering Rule)进行核对,一旦发现某个包的某个或多个部分与过滤规则匹配并且条件为“阻止”的时候,这个包就会被丢弃。适当的设置过滤规则可以让防火墙工作得更安全有效,但是这种技术只能根据预设的过滤规则进行判断,一旦出现一个没有在设计人员意料之中的有害数据包请求,整个防火墙的保护就相当于摆设了。也许你会想,让用户自行添加不行吗?但是别忘了,我们要为是普通计算机用户考虑,并不是所有人都了解网络协议的,如果防火墙工具出现了过滤遗漏问题,他们只能等着被入侵了。一些公司采用定期从网络升级过滤规则的方法,这个创意固然可以方便一部分家庭用户,但是对相对比较专业的用户而言,却不见得就是好事,因为他们可能会有根据自己的机器环境设定和改动的规则,如果这个规则刚好和升级到的规则发生冲突,用户就该郁闷了,而且如果两条规则冲突了,防火墙该听谁的,会不会当场“死给你看”(崩溃)?也许就因为考虑到这些因素,至今我没见过有多少个产品会提供过滤规则更新功能的,这并不能和杀毒软件的病毒特征库升级原理相提并论。为了解决这种鱼与熊掌的问题,人们对包过滤技术进行了改进,这种改进后的技术称为“动态包过滤”(市场上存在一种“基于状态的包过滤防火墙”技术,即Stateful-based Packet Filtering,他们其实是同一类型),与它的前辈相比,动态包过滤功能在保持着原有静态包过滤技术和过滤规则的基础上,会对已经成功与计算机连接的报文传输进行跟踪,并且判断该连接发送的数据包是否会对系统构成威胁,一旦触发其判断机制,防火墙就会自动产生新的临时过滤规则或者把已经存在的过滤规则进行修改,从而阻止该有害数据的继续传输,但是由于动态包过滤需要消耗额外的资源和时间来提取数据包内容进行判断处理,所以与静态包过滤相比,它会降低运行效率,但是静态包过滤已经几乎退出市场了,我们能选择的,大部分也只有动态包过滤防火墙了。
基于包过滤技术的防火墙,其缺点是很显著的:它得以进行正常工作的一切依据都在于过滤规则的实施,但是偏又不能满足建立精细规则的要求(规则数量和防火墙性能成反比),而且它只能工作于网络层和传输层,并不能判断高级协议里的数据是否有害,但是由于它廉价,容易实现,所以它依然服役在各种领域,在技术人员频繁的设置下为我们工作着。
2. 应用代理技术
由于包过滤技术无法提供完善的数据保护措施,而且一些特殊的报文攻击仅仅使用过滤的方法并不能消除危害(如SYN攻击、ICMP洪水等),因此人们需要一种更全面的防火墙保护技术,在这样的需求背景下,采用“应用代理”(Application Proxy)技术的防火墙诞生了。我们的读者还记得“代理”的概念吗?代理服务器作为一个为用户保密或者突破访问限制的数据转发通道,在网络上应用广泛。我们都知道,一个完整的代理设备包含一个服务端和客户端,服务端接收来自用户的请求,调用自身的客户端模拟一个基于用户请求的连接到目标服务器,再把目标服务器返回的数据转发给用户,完成一次代理工作过程。那么,如果在一台代理设备的服务端和客户端之间连接一个过滤措施呢?这样的思想便造就了“应用代理”防火墙,这种防火墙实际上就是一台小型的带有数据检测过滤功能的透明代理服务器(Transparent Proxy),但是它并不是单纯的在一个代理设备中嵌入包过滤技术,而是一种被称为“应用协议分析”(Application Protocol Analysis)的新技术。
“应用协议分析”技术工作在OSI模型的最高层——应用层上,在这一层里能接触到的所有数据都是最终形式,也就是说,防火墙“看到”的数据和我们看到的是一样的,而不是一个个带着地址端口协议等原始内容的数据包,因而它可以实现更高级的数据检测过程。整个代理防火墙把自身映射为一条透明线路,在用户方面和外界线路看来,它们之间的连接并没有任何阻碍,但是这个连接的数据收发实际上是经过了代理防火墙转向的,当外界数据进入代理防火墙的客户端时,“应用协议分析”模块便根据应用层协议处理这个数据,通过预置的处理规则(没错,又是规则,防火墙离不开规则)查询这个数据是否带有危害,由于这一层面对的已经不再是组合有限的报文协议,甚至可以识别类似于“GET /sql.asp?id=1 and 1”的数据内容,所以防火墙不仅能根据数据层提供的信息判断数据,更能像管理员分析服务器日志那样“看”内容辨危害。而且由于工作在应用层,防火墙还可以实现双向限制,在过滤外部网络有害数据的同时也监控着内部网络的信息,管理员可以配置防火墙实现一个身份验证和连接时限的功能,进一步防止内部网络信息泄漏的隐患。最后,由于代理防火墙采取是代理机制进行工作,内外部网络之间的通信都需先经过代理服务器审核,通过后再由代理服务器连接,根本没有给分隔在内外部网络两边的计算机直接会话的机会,可以避免入侵者使用“数据驱动”攻击方式(一种能通过包过滤技术防火墙规则的数据报文,但是当它进入计算机处理后,却变成能够修改系统设置和用户数据的恶意代码)渗透内部网络,可以说,“应用代理”是比包过滤技术更完善的防火墙技术。
但是,似乎任何东西都不可能逃避“墨菲定律”的规则,代理型防火墙的结构特征偏偏正是它的最大缺点,由于它是基于代理技术的,通过防火墙的每个连接都必须建立在为之创建的代理程序进程上,而代理进程自身是要消耗一定时间的,更何况代理进程里还有一套复杂的协议分析机制在同时工作,于是数据在通过代理防火墙时就不可避免的发生数据迟滞现象,换个形象的说法,每个数据连接在经过代理防火墙时都会先被请进保安室喝杯茶搜搜身再继续赶路,而保安的工作速度并不能很快。代理防火墙是以牺牲速度为代价换取了比包过滤防火墙更高的安全性能,在网络吞吐量不是很大的情况下,也许用户不会察觉到什么,然而到了数据交换频繁的时刻,代理防火墙就成了整个网络的瓶颈,而且一旦防火墙的硬件配置支撑不住高强度的数据流量而发生罢工,整个网络可能就会因此瘫痪了。所以,代理防火墙的普及范围还远远不及包过滤型防火墙,而在软件防火墙方面更是几乎没见过类似产品了——单机并不具备代理技术所需的条件,所以就目前整个庞大的软件防火墙市场来说,代理防火墙很难有立足之地。
3 .状态检测技术
这是继“包过滤”技术和“应用代理”技术后发展的防火墙技术,它是CheckPoint技术公司在基于“包过滤”原理的“动态包过滤”技术发展而来的,与之类似的有其他厂商联合发展的“深度包检测”(Deep Packet Inspection)技术。这种防火墙技术通过一种被称为“状态监视”的模块,在不影响网络安全正常工作的前提下采用抽取相关数据的方法对网络通信的各个层次实行监测,并根据各种过滤规则作出安全决策。
“状态监视”(Stateful Inspection)技术在保留了对每个数据包的头部、协议、地址、端口、类型等信息进行分析的基础上,进一步发展了“会话过滤”(Session Filtering)功能,在每个连接建立时,防火墙会为这个连接构造一个会话状态,里面包含了这个连接数据包的所有信息,以后这个连接都基于这个状态信息进行,这种检测的高明之处是能对每个数据包的内容进行监视,一旦建立了一个会话状态,则此后的数据传输都要以此会话状态作为依据,例如一个连接的数据包源端口是8000,那么在以后的数据传输过程里防火墙都会审核这个包的源端口还是不是8000,否则这个数据包就被拦截,而且会话状态的保留是有时间限制的,在超时的范围内如果没有再进行数据传输,这个会话状态就会被丢弃。状态监视可以对包内容进行分析,从而摆脱了传统防火墙仅局限于几个包头部信息的检测弱点,而且这种防火墙不必开放过多端口,进一步杜绝了可能因为开放端口过多而带来的安全隐患。
由于状态监视技术相当于结合了包过滤技术和应用代理技术,因此是最先进的,但是由于实现技术复杂,在实际应用中还不能做到真正的完全有效的数据安全检测,而且在一般的计算机硬件系统上很难设计出基于此技术的完善防御措施(市面上大部分软件防火墙使用的其实只是包过滤技术加上一点其他新特性而已)。