两台linux服务器，一台共享存储，但是一台linux识别出来的是devsdb,一台识别出来的是devsdc,

用设备号来识别硬盘是不靠谱的 ，设备号会随着本机的硬盘数量变化而变化。最好的方法是依靠UUID来识别，不管硬盘拿到哪台服务器都不会变化。
ls /dev/disk/by-uuid -l
可以显示硬盘UUID号
对 /dev/disk/by-uuid/xxxxxxxxx /dev/sdax *** 作效果是一样的
-------StarOS软件打包组为您解答

般会遇到以下N种情况,你看有没有你的那种: 调制解调器不工作。 原因： 调制解调器不兼容。 解决方案： 如果有另一台计算机可以访问 Internet，那么请查看兼容调制解调器的列表。要查找由 Windows *** 作系统支持的硬件，请访问 Microsoft 网站上的

首先，要 *** 作蓝牙，先要在AndroidManifestxml里加入权限
<uses-permissionandroid:name="androidpermissionBLUETOOTH_ADMIN" />
<uses-permissionandroid:name="androidpermissionBLUETOOTH" />
然后，看下api，Android所有关于蓝牙开发的类都在androidbluetooth包下。 而需要用到了就只有几个而已：
1BluetoothAdapter 顾名思义，蓝牙适配器，直到我们建立bluetoothSocket连接之前，都要不断 *** 作它BluetoothAdapter里的方法很多，常用的有以下几个：cancelDiscovery() 根据字面意思，是取消发现，也就是说正在搜索设备的时候调用这个方法将不再继续搜索disable()关闭蓝牙enable()打开蓝牙，这个方法打开蓝牙不会d出提示，更多的时候需要问下用户是否打开，一下这两行代码同样是打开蓝牙，不过会提示用户：Intemtenabler=new Intent(BluetoothAdapterACTION_REQUEST_ENABLE);
startActivityForResult(enabler,reCode);//同startActivity(enabler);
getAddress()获取本地蓝牙地址getDefaultAdapter()获取默认BluetoothAdapter，实际上，也只有这一种方法获取BluetoothAdaptergetName()获取本地蓝牙名称getRemoteDevice(String address)根据蓝牙地址获取远程蓝牙设备getState()获取本地蓝牙适配器当前状态（感觉可能调试的时候更需要）isDiscovering()判断当前是否正在查找设备，是返回trueisEnabled()判断蓝牙是否打开，已打开返回true，否则，返回falselistenUsingRfcommWithServiceRecord(String name,UUID uuid)根据名称，UUID创建并返回BluetoothServerSocket，这是创建BluetoothSocket服务器端的第一步startDiscovery()开始搜索，这是搜索的第一步。 2BluetoothDevice看名字就知道，这个类描述了一个蓝牙设备createRfcommSocketToServiceRecord(UUIDuuid)根据UUID创建并返回一个BluetoothSocket这个方法也是我们获取BluetoothDevice的目的——创建BluetoothSocket
这个类其他的方法，如getAddress(),getName(),同BluetoothAdapter；
3BluetoothServerSocket如果去除了Bluetooth相信大家一定再熟悉不过了，既然是Socket，方法就应该都差不多，这个类一种只有三个方法
两个重载的accept(),accept(inttimeout)两者的区别在于后面的方法指定了过时时间，需要注意的是，执行这两个方法的时候，直到接收到了客户端的请求（或是过期之后），都会阻塞线程，应该放在新线程里运行。
还有一点需要注意的是，这两个方法都返回一个BluetoothSocket，最后的连接也是服务器端与客户端的两个BluetoothSocket的连接。
4BluetoothSocket,跟BluetoothServerSocket相对，是客户端一共5个方法，不出意外，都会用到close(),关闭connect()连接getInptuStream()获取输入流getOutputStream()获取输出流getRemoteDevice()获取远程设备，这里指的是获取bluetoothSocket指定连接的那个远程蓝牙设备 。

购买新服务器后有数据盘，需要我们自己来挂载的。我们给服务器添加新的硬盘的时候都需要进行挂载 *** 作，本文简要记录挂载 *** 作过程。

查看硬盘信息

首先我们使用命令df -TH查看当前系统挂载的情况：

我们看到并没有挂载新的数据盘，数据盘是200多G的。

然后通过命令fdisk -l查看硬盘信息。

可以看到有两块硬盘/dev/vda和/dev/vdb，启动vda是系统盘，vdb是我们新增的数据盘。也就是说系统发现了新增的数据盘/dev/vdb，但并没有挂载。注意有时候新增数据盘不叫vdb，它有可能叫vde。

执行挂载命令

1、执行命令fdisk /dev/vdb，进入fdisk模式，开始对新增数据盘执行分区 *** 作。

在回显信息中，输入n后回车，接下来的 *** 作全部回车默认即可。在上图中最后回车回显的信息中告诉我们有一个200G的硬盘分区以及建立好了。

2、接下来输入p，回车，查看新建分区的详细信息。

如上图，接着输入w保存，将分区结果写入分区表中。

如回显信息如下，则说明分区成功：

3、执行命令partprobe，将新的分区表变更同步至 *** 作系统。

4、执行以下命令，将新建分区文件系统设为系统所需格式。

            mkfs -t ext4 /dev/vdb1

5、将新建的分区挂载到/mnt/datadisk挂载点，/mnt/datadisk是我们系统新建的一个挂载点，即目录，如果目录不存在要提前新建好，可以自己定义挂载目录。

            mount /dev/vdb1 /mnt/datadisk

6、使用命令df -Th查看磁盘挂载情况。

上图中表示新的磁盘/dev/vdb1已经成功挂载到/mnt/datadisk。

开机自动挂载

挂载好的磁盘需要设置开机自动挂载，我们不采用/etc/fstab直接指定 /dev/vdb1的方法，而推荐使用UUID来配置自动挂载数据盘。

先执行命令blkid /dev/vdb1，查询磁盘分区的UUID：

           /dev/vdb1: UUID="1d4e1d9d-d15c-1273-8442-2303b05b96ad" TYPE="ext4"

然后编辑/etc/fstab，在末尾增加一行：

             UUID=1d4e1d9d-d15c-1273-8442-2303b05b96ad /mnt/datadisk ext4 defaults 1 1

把UUID和目录换成你自己的即可。

最后，重启机器，使用df -TH查看挂载情况，如果能看到新增的磁盘挂载信息则大功告成。

qq群：311602501

直接在你要update的文件夹里面找到隐藏的文件夹svn,（不会找隐藏文件去百度），找到svn后把它删除干掉，然后重新chekout就可以了，听他们瞎JB吹，整天BB uuid

随着wx的普及对开发同学来说一些业务场景会使用到“扫码登录”功能，特别是PC网页端，在此之前没有这方面的开发经历，所以接到这个需求的时候还是有点慌的，最终通过查阅网上的资料以及老大的指导下实现了这个功能，目前已经投入使用，实现之后还是蛮兴奋的。特此记录一下实现的过程。

扫码登陆的实现需要手机端的服务器和Web端的服务器配合实现。大致分为以下几步：

step1：网页端请求登陆二维码

要实现网页版的扫码登陆，用户必须先要请求一个登陆的二维码。Web端的服务器收到用户申请登陆二维码的请求后，会随机生成一个uuid（这个uuid作为页面的唯一标识符），并且会将这个uuid当做一个键值对的key存入后台Redis。存入Redis的这个键值对的value是什么我们待会再说。

需要注意的是存入Redis的键值对必须设置一个过期时间，不然的话拿着这个uuid登陆一次后就一直处于登陆状态了。

当浏览器端拿到Web服务端返回的二维码信息后，解析其中的uuid，并拿这个uuid不断去后台轮询是否已经登陆成功。如果后台已经登陆成功，Web端就自动跳转到登陆成功页面。不然的话会一直轮询，直到二维码失效（这里我们发现给二维码设置有效时间真的很有必要，如果二维码没有有效时间的话，会不断的轮询后台，给后台造成很大的压力）。

那么上面的关键点是Web端服务器是怎么判断用户是否已经扫码登陆成功过的呢？ 请看下面的步骤。

step2：手机端将用户id存入Redis

用户请求到二维码后，就开始拿出手机，打开相应的App扫描二维码。扫描过程中手机会将uuid和手机端登陆后获得的token信息一起提交到手机端服务器。

手机端服务器会先拿token信息判断这个用户是否合法，是否已经正常登陆。如果判断已经正常登陆，那么会将这个用户的userId和提交过来的uuid当做一个键值对（uudi-userId）存入Redis。这边回答了步骤一种留下的问题。

简单来讲手机端做的工作就这么多。让我们继续回到Web端。

step3：web端轮询成功

步骤一中讲到：二维码登陆页会不停的轮询是否登陆成功。这边的依据就是Redis中存在uuid-userId键值对。如果这个键值对已经存在，说明手机端已经扫码登陆过。

Web端服务器一旦判断到手机端已经扫码登陆过，就可以拿着userId进行登陆。并将必要的用户信息和token信息返回Web前端。至此Web端登陆成功。

本文记录了一个扫码登陆的简单版本，但是也能描述扫码登陆的大致原理。实际开发过程中应该还是有许多细节需要考虑。比如安全问题等。具体的还是需要我们进行实战了。

欢迎大家一起讨论~

只可能是服务器出问题了，换个时间点再试试就好了
uuid一般是网站内部使用的，在页面上不会直接显示这部分内容，如果出现了，那么肯定是服务器出问题了，只能重新登入网站或者换个时间点访问
按照实名认证的基本逻辑流程
首先你要是个已登陆的用户，就是说你在其他页面上已经通过显式（通过用户名和密码）或者隐式（通过”记住我“功能）登陆进入天猫的网站，在这一步，服务器会分配给你一个唯一的字符串也就是uuid，当然不会显示出来。
然后，你要通过网站内某个链接进入到实名认证页面，这里，服务器首先检查你当前登录的用户与分配给你的uuid是否符合，如果符合则允许你进一步处理，否则会报如上错误。这样的检查会在你进行任意一项关键 *** 作时进行，如提交你的认证材料，更改你的认证信息等
正常情况下，你在进行你的 *** 作时不会出错，除非你是个hack，伪造了认证数据，否则浏览器这边（也就是你这一边）一般不会出任何问题

---