手机版我的世界服务器op怎么给别人VIP

第1你是op

第2vip指令没用被禁用

然后输/addvip 玩家名

svip就输/addsvip 玩家名

答部分都是这个指令如果这个指令不行就试试输

/vip 会出现帮助列表

如果问题还没有解决那就只能一点一点翻帮助手册了。帮助手册指令

/help

LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，现在已经是 Linux标准内核的一部分。LVS是一种叫基于TCP/IP的负载均衡技术，转发效率极高，具有处理百万计并发连接请求的能力。

LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS模块是LVS集群的核心软件模块，它安装在LVS集群作为负载均衡的主节点上，虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务（VS），然后访问请求由负载均衡器（LB）调度到后端真实服务器（RS）中，由RS实际处理用户的请求给返回响应。

根据负载均衡器转发客户端请求以及RS返回响应机制的不同，将IPVS的转发模式分为三种：VS/NAT，VS/DR，VS/TUN

DR模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，但是会改写请求包的MAC地址为后端RS的MAC地址，然后将数据包转发；真实服务器处理请求后，响应包直接回给客户端，不再经过负载均衡器。所以DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，比如请求视频等大文件。

DR模式的特点：

LB只是将数据包的MAC地址改写为RS的MAC地址，然后转发给相应的RS。

因为LB转发时并不会改写数据包的目的IP，所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包，而不是丢弃，必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则RS会直接丢弃该数据包！

因为LB不会改写数据包的目的端口，所以RS服务的监听端口必须和虚拟服务端口一致，否则RS会直接拒绝该数据包。

因为RS收到的请求数据包的源IP是客户端的IP，所以理所当然RS的响应会直接回给客户端，而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。

因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址，所以要能够查询到RS的MAC。而要获取到RS的MAC，则需要保证二者位于一个子网，否则LB只能获取到RS网关的MAC地址。

NAT模式下，请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后，LB会对请求包做目的地址转换（DNAT），将请求包的目的IP改写为RS的IP。当收到RS的响应后，LB会对响应包做源地址转换（SNAT），将响应包的源IP改写为LB的IP。

NAT模式的特点：

对于请求包，会进行DNAT；对于响应包，会进行SNAT。

虽然LB在转发过程中做了NAT转换，但是因为只是做了部分地址转发，所以RS收到的请求包里是能看到客户端IP的。

因为RS收到的请求包源IP是客户端的IP，为了保证响应包在返回时能走到LB上面，所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然，如果客户端的IP是固定的，也可以在RS上添加明细路由指向LB的虚拟服务IP，不用改默认网关。

因为需要将RS的默认网关配置为LB的虚拟服务IP地址，所以需要保证LB和RS位于同一子网。

又因为需要保证RS的响应包能走回到LB上，则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC，响应包就直接回给客户端了，不会走网关，也就走不到LB上面了。这时候由于没有LB做SNAT，客户端收到的响应包源IP是RS的IP，而客户端的请求包目的IP是LB的虚拟服务IP，这时候客户端无法识别响应包，会直接丢弃。

IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可 能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，可以利用IP隧道的原理将一组服务器上的网络服 务组成在一个IP地址上的虚拟网络服务。各个服务器将VIP地址配置在自己的IP隧道设备上。

它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况， 动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为 VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

LB会根据RS上配置的权重，将消息按权重比分发到不同的RS上。可以给性能更好的RS节点配置更高的权重，提升集群整体的性能。

最小连接调度（Least-Connection Scheduling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务 器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

加权最小连接调度（Weighted Least-Connection Scheduling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

基于局部性的最少链接调度（Locality-Based Least Connections Scheduling，以下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中 客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的 请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

带复制的基于局部性最少链接调度（Locality-Based Least Connections with Replication Scheduling，以下简称为LBLCR）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站 点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现 在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热 门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器 数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。

目标地址散列调度（Destination Hashing Scheduling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

源地址散列调度（Source Hashing Scheduling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。

客户端发送对VIP的请求，lvs负载到后端某一台server，后端server处理后，直接封包回送客户端，源IP地址一定是lvs上面配的那个公网服务地址，也就后端server要配置这个ip，后端server收到的数据包是lvs没有变动过的（IP：vip），多个server，接入互联网的server持有相同的IP，是不允许的，因此，必须将后端server中的vip隐藏起来（对外隐藏，对自己可见）

VIP: 虚拟服务器地址

DIP: 转发的网络地址

1，和RIP通信：ARP协议，获取Real Server的RIP：MAC地址；

2，转发Client的数据包到RIP上，RIP上要求有VIP（对外隐藏VIP）；

RIP: 后端真实主机(后端服务器)

CIP: 客户端IP地址

对外隐藏，对内可见

kernel parameter:

目标mac地址为全F，交换机触发广播

arp_ignore: 定义接收到ARP请求时的响应级别；

0：只要本地配置的有相应地址，就给予响应；

1：仅在请求的目标(MAC)地址配置请求

到达的接口上的时候，才给予响应；

arp_announce：定义将自己地址向外通告时的通告级别；

0：将本地任何接口上的任何地址向外通告；

1：试图仅向目标网络通告与其网络匹配的地址；

2：仅向与本地接口上地址匹配的网络进行通告；

lvs 主机：192.168.56.118

RIP主机：也就是需要负载的服务器，192.168.56.101-103

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，后来将lvs嵌入到linux内核，叫做ipvs

ipvs参数

保存规则

-S

载入此前的规则：

-R

配置lvs的VIP

确保/proc/sys/net/ipv4/ip_forward 内容是1

调整RS的响应。通告级别（每一台RS都配）：

配置RS的VIP（每一台RS都配）

启动RS上的httpd

编写测试文件

启动httpd

客户端验证：

RIP：80 能显示

VIP：80不能显示

负载服务器安装LVS管理工具—ipvsadm

浏览器刷新: 访问vip：80

在DR模式中是所有服务机共享一个VIP，但是在IP隧道模式中，就相当于主代理机将包经过自己打包之后，将IP转化成公网可传递的IP，并将消息经过自己又一次的打包，发送给真实服务器，真实服务器对这个请求作出响应，这样就达到一个可以跨地区的传输。并且也避免了DR模式中代理机与真实服务机必须在同一局域网的不便。

说明：

1、当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP 。

2、PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

3、IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。此时源IP为DIP，目标IP为RIP

4、POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。此时源IP为DIP，目标IP为RIP

5、RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。此时的源IP地址为VIP，目标IP为CIP

RIP、VIP、DIP全是公网地址

RS的网关不会也不可能指向DIP

所有的请求报文经由Director Server，但响应报文必须不能进过Director Server

不支持端口映射

RS的系统必须支持隧道

LVS服务器：192.168.56.100

RS服务器：192.168.56.101，192.168.56.102，192.168.56.103

4.4.5 ### 系统配置 vim /etc/sysctl.conf

4.5.5 ### 系统配置 vim /etc/sysctl.conf

用户组管理所涉及的文件有2个：\plugins\GroupManager\worlds\world下的“groups.yml”和“users.yml”（注意.yml格式要用写字板打开，推荐EmEditor等软件）。

权限有两种添加方法，一种是在游戏中使用命令添加（前提是你有添加的权限，OP即可），另一种是更改文件来添加权限（比命令的一个一个添加快，适合老手），

groups.yml

说明（注意格式一定要保持如下）：

开头不空格的是“groups”，文件固定设置不要更改；

开头空2格的是组别，默认有（级别依次提高）：“default（默认）”、“Builder（建筑家）”、“Moderator（调解人）”、“SemiAdmin（副管理）”、“Admin（总管理）”；

开头空4格的是各组的各项设置，名称不需要修改；

开头为“- ”的是权限和功能，由插件提供；

开头空6格的是用户组的属性信息。

文件组设置一般格式：

groups: （这个要保持在文件最上处）

XXX: （XXX的含义是你可以自行增减用户组，名称任意，只要保持各设置格式相同即可）

default: false （该项设置玩家第一次进入游戏时，是否自动归入改组，true是，false否，下同）

permissions: （该项设置玩家的权限，在下一行之后添加，该项请看完后面的设置再更改）

- essentials.* （*代表ESS插件某一权限，例如“sethome”为设置家等，如果保持*，该组则拥有Essentials插件的所有权限）

- '*' （仅仅为'*'（注意引号）则是指该组拥有所有的权限（包括上面的））

- XXX.XXX （这是其他插件的权限格式，长短，点数量不定，作者应该在帖子中作说明）

inheritance: （意为继承，在下一行之后添加其它某一组（级别相邻或相同即可），之后XXX组就拥有所添加的组的所有权限，没有则改为“inheritance: []”，下方组也不添加）

- default （例如该项设置了默认组，则XXX组就拥有默认组所有权限（你不用再在“permissions”中添加命令了））

info: （用户组属性）

prefix: '&e' （前缀，若将引号中的内容改为“&c[VIP]&2”，该组所有玩家名则会显示为：[VIP]绿名，输入“/list”查看在线人数时就可以看到。颜色设置在这里看）

build: true （该组是否能修改地形（注：刚安装插件时，默认组此项为false））

suffix: '' （尾缀，好吧，这项我没用过，应该和“prefix”一样功能，不过在昵称尾部）

users.yml

说明（注意格式一定要保持如下 ）：

开头不空格的是“users:”，文件固定设置不要更改；

开头空2格的是玩家；

开头空4格的是各组的各项设置，名称不需要修改；

该项设置很简单，一般格式：

users: （该项固定在文件顶部）

123: （我们以一个名叫“123”的玩家举例吧）

subgroups: [] （子用户组，类似于上面的“继承”，单独对该玩家有效（上面的“继承”同样有效），冒号后接空格+[]表示“无”，下同）

permissions: [] （权限，仅该玩家拥有（添加方法同groups.yml），该两项设置一般不需更改）

group: XXX （玩家所在用户组）

P·S：若保持空的状态，通过下文的命令来进行编辑，则需要改为：

users: {}

复制代码

以上两个文件，所有同一横行后有设置的项，冒号后都有一个空格。

用户组命令（在游戏中和服务器中进行修改）

注意：在游戏中输入命令前需要加“/”，在服务器中则不用；在游戏中输入“/help”（第1页）或“/help *”（*为页数）可查看命令及英文说明。

进行更改前提命令：

manselect world 选择world为需要更改权限的地图；

mantogglevalidate 允许更改不在线的用户（若只更改在线的，则无需输入）；

请确认输入此命令后server窗口显示如下字样：

[INFO] Validade if player is online, now set to: false （玩家在线时才生效，现在设置为：否（意思就是不在线的也能修改了））

[INFO] From now on you can edit players not connected... BUT: （从现在起你能编辑未连接的玩家…但是：）

[INFO] From now on you should type the whole name of the player, correctly. （从现在开始你需要正确地输入被更改玩家的全名。）

若显示为：

[INFO] Validade if player is online, now set to: true

则需要再输入一遍命令，确保为false（这样你才能修改不在线的）。

以下是自行用户及组设置（man后接u是对用户，接g是对组设置）：

manuadd 123 XXX 将玩家123添加到XXX用户组；

manudel 123 将玩家123变为默认组；

manuaddsub 123 XXX 将XXX用户组添加到玩家123的子用户组列表中；

manudelsub 123 XXX 将XXX用户组从玩家123的子列表中剔除；

manuaddp 123 essentials.* 为玩家123单独增加essentials.*权限（由于大部分权限都由Essentials基础插件提供，所以这是一般形式）；

manudelp 123 essentials.* 删除玩家123拥有的essentials.*权限；

manulistp 123 列出玩家123所拥有的权限；

manucheckp 123 essentials.* 检查玩家123是否拥有essentials.*权限，并寻找出处（用户组）；

manuaddv 123 prefix &1 设置玩家123的prefix变量为&1（变量目前有prefix（前缀）、suffix（尾缀）、build（破坏方块）三种，已有效）；

manudelv 123 prefix 删除玩家123的prefix变量；

manulistv 123 列出玩家123所拥有的变量（虽然无效，但看还是能看的）；

manucheckv 123 prefix 查看玩家123的prefix变量属性（这里看的是用户组里的）；

mangadd XXX 添加名为XXX的用户组；

mangdel XXX 删除名为XXX的用户组；

mangaddp XXX essentials.* 为用户组XXX增加essentials.*权限；

mangdelp XXX essentials.* 删除用户组XXX拥有的essentials.*权限；

manglistp XXX 列出用户组XXX所拥有的权限；

mangcheckp XXX essentials.* 检查用户组XXX是否拥有essentials.*权限，并寻找出处；

mangaddv XXX prefix &1 设置用户组XXX的prefix变量为&1；

mangdelv XXX prefix 删除用户组XXX的prefix变量；

manglistv XXX 列出用户组XXX所拥有的变量；

mangcheckv XXX prefix 查看用户组XXX的prefix变量属性；

mangaddi XXX1 XXX2 使用户组XXX1继承用户组XXX2的权限；

mangdeli XXX1 XXX2 将用户组XXX2从用户组XXX1的继承列表中删除（这个命令经测试发现有问题，删除不了）；

manpromote 123 XXX 将玩家123升级到XXX用户组；

mandemote 123 XXX 将玩家123降级到XXX用户组（其实这两个命令都是改变组别的，升级降级无实在含义）；

listgroups 列出目前所存在的用户组。

资料来源 我比较尊重原帖作者

http://www.mcbbs.net/forum.php?mod=viewthread&tid=5531&page=1

---