JumpCloud 是一个基于云的 LDAP 服务。 如果你的项目小组成员在 10 个或者 10 个以下的话，你可以免费使用 JumpCloud 服务器。 这篇文章假设的是你已经设置好了 JumpCloud 的云服务，并且已经注册了 JumpCloud 的管理员和后台访问权限。同时你希望使用 Apache Directory Studio 来连接 JumpCloud 提供的云 LDAP 服务。 登录 JumpCloud 的管理员后台 管理员后台的地址为：https://console.jumpcloud.com/login 在这里你需要输入你管理员的账号和密码，如果你是用户的话，你需要使用你用户的账号和密码在用户前端进行登录。 登录成功后，你可以看到所有的用户列表。 如果是管理员的话，你可以选择你管理员的用户名称。 然后找到 LDAP 的 DN 名称。 这个就是你 JumpCloud 管理员的 DN，你需要将这一长串字符串拷贝下来。 在你使用 Apache Directory Studio 进行登录的时候，你需要这个 DN 才能够进行登录。 Apache Directory Studio 创建连接 登录 Apache Directory Studio ，然后可以在左侧的下面配置连接。 配置 JumpCloud 的网络参数。 Hostname: ldap.jumpcloud.com Port: 389 然后可以检查网络参数。 配置 JumpCloud 的授权 在 DN 粘贴上面我们提到的需要你保存的 DN。 在密码部分输入你登录 JumpCloud 控制台的密码。 在配置完成后，可以单击检查授权来查看你的用户信息是否正确。 如果你的配置是正确的话，你将会看到授权已经成功的提示，这个时候你就可以应用并且关闭连接配置界面了。 浏览目录 在右下角双击连接，然后将会在左上显示一个 DIT。 如果你双击 DIT 的话，你可能看不到任何你存储到 JumpCloud 上面的用户，这是因为你 DN 的 Base DN 路径不正确。 其实也不能说不正确，因为你的用户授权的 CN 比较低，你需要返回到上一级。 右键，然后在弹出的对话框中选择 Go to Dn 然后在弹出的对话框中输入： o=*********************,dc=jumpcloud,dc=com 其实就是在上面拷贝的 DN，但是这个 DN 需要去掉 cn 部分的内容。 这个操作的目的就是在授权成功后，返回到 上一级的 DN，因为你的用户和用户组信息都会在上一级的 DN 上面。 然后你就可以在这里查看用户和用户组的信息了。 这里能够查看到的信息应该是与 JumpCloud 上面配置的用户和用户组信息对应的。 至此，你的 Apache Directory Studio 和 JumpCloud 就已经完全配置成功并且建立连接了。 https://www.ossez.com/t/apache-directory-studio-jumpcloud/527
在编译的时候有下面的警告提示： Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use ‘–warning-mode all’ to show the individual deprecation warnings. See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings CONFIGURE SUCCESSFUL in 14s 如何进行查看和操作？ 解决办法 其实这是一个比较简单的问题。 上面的提示信息已经告诉你怎么运行了。 你可以运行命令 gradlew --warning-mode all 在输出中，你可以看到下面的信息 Configure project : The compile configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 7.0. Please use the implementation configuration instead. Consult the upgrading guide for further information: https:// docs.gradle.org/6.3/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations at build_45djmc9u5bi478od1utks361r$_run_closure1$_closure8.doCall(C:\WorkDir\Ossez-Com\USData\Source-Code\covid-19\build.gradle:53) (Run with --stacktrace to get the full stack trace of this deprecation warning.) 上面的内容已经很明确的告诉你存在兼容性问题的地方在哪里。 根据提示的内容进行修改就可以了。 上面的说明是： Please use the implementation configuration instead 你使用 implementation 配置就行了。
什么是 RDN，RDN 和 DN 又有什么关系呢？ 很多第一次接触到 LDAP 的童鞋，经常会被一堆名字搞得晕头转向。 RDN（relative distinguished name）中文翻译就是相对专有名字。 一般指dn逗号最左边的部分，如 cn=baby。 DN 是由多个 RDN 组织而成的。 CN=cwikius,ou=Users,dc=jumpcloud,dc=com 上面的 RDN 就不是一个了，这个 DN 的 RDN 就有 4 个，分别是： CN=cwikius ou=Users dc=jumpcloud dc=com 简单来说，就是 DN 字符串是由一组 RDN 组成的。 上面的这个图应该能比较明确的表达 DN 和 RDN 的关系了。 从数量上来说，一个 DN 可以有一个或者多个 RDN。 https://www.ossez.com/t/ldap-rdn/525
整体来看是对留学生的管理趋于严格。 本来留学生在美国就是弱势，每次和 USCIS 打交道都会提心吊胆。这个政策不是仅仅针对中国的，是针对全部的留学生。 想到可能有下面 3 类影响： 如果是想留这边混日子，顺便做点代购，不停通过换学校保持身份合法性的留学生来说可能造成一些障碍了。 如果就是想读书， 然后回国发展的，这个政策无所谓。 如果想通过读书并且留美国的，那么就逼着你早点准备，早点合理安排计划和规划，毕业后赶紧好好找个工作，走正常渠道去解决问题。 整体来看也许就是 USCIS 在堵上以前留下来的一些空子。
LDAP 是轻量目录访问协议，英文全称是LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL，一般都简称为 LDAP。 读写效率非常高 对读操作进行优化的一种数据库，在读写比例大于7比1的情况下，LDAP会体现出极高的性能。这个特性正适合了身份认证的需要。 开放的标准协议 不同于SQL数据库，LDAP的客户端是跨平台的，并且对几乎所有的程序语言都有标准的API接口。 即使是改变了LDAP数据库产品的提供厂商，开发人员也不用担心需要修改程序才能适应新的数据库产品。这个优势是使用SQL语言进行查询的关系型数据库难以达到的。 强认证方式 可以达到很高的安全级别。 在国际化方面，LDAP使用了UTF-8编码来存储各种语言的字符。 OpenLDAP开源实现 OpenLDAP还包含了很多有创造性的新功能，能满足大多数使用者的要求。 OpenLDAP是其中最轻便且消耗系统资源最少的一个。 OpenLDAP是开源软件，近年国内很多公司开发的LDAP产品都是基于OpenLDAP开发的。 灵活添加数据类型 LDAP是根据schema的内容定义各种属性之间的从属关系及匹配模式的。 例如在关系型数据库中如果要为用户增加一个属性，就要在用户表中增加一个字段，在拥有庞大数量用户的情况下是十分困难的，需要改变表结构。 但LDAP只需要在schema中加入新的属性，不会由于用户的属性增多而影响查询性能。 数据存储是树结构 整棵树的任何一个分支都可以单独放在一个服务器中进行分布式管理，不仅有利于做服务器的负载均衡，还方便了跨地域的服务器部署。 这个优势在查询负载大或企业在不同地域都设有分公司的时候体现尤为明显。 LDAP 的特点 LDAP 是一种网络协议而不是数据库，而且LDAP的目录不是关系型的，没有RDBMS那么复杂， LDAP不支持数据库的Transaction机制，纯粹的无状态、请求-响应的工作模式。 LDAP不能存储BLOB，LDAP的读写操作是非对称的，读非常方便，写比较麻烦， LDAP支持复杂的查询过滤器(filter)，可以完成很多类似数据库的查询功能。 LDAP使用树状结构，接近于公司组织结构、文件目录结构、域名结构等我们耳熟能详的东西。 LDAP使用简单、接口标准，并支持SSL访问。 LDAP与NIS相比 1.LDAP是标准的、跨平台的，在Windows下也能支持。 2.LDAP支持非匿名的访问，而且有比较复杂的访问控制机制(如ACL)，安全性似乎更好一些。 3.LDAP支持很多复杂的查询方式。 4.LDAP的用途较NIS更为广泛，各种服务都可以和LDAP挂钩。 LDAP 的主要应用场景 .网络服务：DNS服务 2.统一认证服务： 3.Linux PAM (ssh, login, cvs. . . ) 4.Apache访问控制 5.各种服务登录(ftpd, php based, perl based, python based. . . ) 6.个人信息类，如地址簿 7.服务器信息，如帐号管理、邮件服务等 作为一般的公司来说，LDAP 很多时候被用来权限认证，软件和内部系统的用户管理和认证。 设想下，你有一个软件公司，公司里面有超过上千的员工，你们公司可能会用到各种软件，比如说 JIRA，Wiki，代码库，考勤系统等等。 LDAP 就充当了授权的这个角色，你可用在 LDAP 中对用户进行授权，分组，这样你的用户就会具有不通过软件平台的访问权限了。 现在公司的流动性也非常强，每天都会有入职的也会有离职的，对每一个人都要进行授权，撤销权限，跨域管理等等与用户有关的操作，在大一点的公司这个简直就是灾难。 LDAP 能够很好的解决这个问题。 Spring Data 提供了基于 LDAP 协议访问的 API，需要注意的是，在开发的时候需要将 LDAP 认为是一个数据库，只是与普通数据库不同的是，LDAP 使用的是 LDAP 的协议。 否则，在用户分组查询，等基于 Spring Data LDAP 的编程过程中，你可能会感到非常困惑。 https://www.ossez.com/t/ldap/523
DN 的英文名称是（distinguished name），直接翻译过来就是专有名称。 简单的就可以理解为一个路径就对了。 这个路径可以指向 OU ，也可以指到 CN。 其中 DN 有三个属性，分别是CN，OU，DC。 DC (Domain Component) CN (Common Name) OU (Organizational Unit) O (Organization Name) O 是可选项，有时候你不一定能够看得到。 下面是 X.500 的属性列表： String X.500 AttributeType CN commonName L localityName ST stateOrProvinceName O organizationName OU organizationalUnitName C countryName STREET streetAddress DC domainComponent UID userid 可以理解成 DC 是最高的，叫做域名，基本上所有的 ldap 服务都会至少有一个 DC。 在 DC 下一级就会有一个 OU，OU 可以理解为一个组织单元，我们可以有多个组织单元。你可以在组织单元中组织用户组，也可以在组织单元中组织用户，你还可以在组织单元中组织组织单元。 在 OU 下面就是 CN 了，可以理解是 CN 就是一个具体的实例了，比如说一个具体的用户。 所以要定位一个实例，那么路径就是 CN - OU - DC 你可能会有多个 OU，多个 DC，但是最后都会定位到最高一级的 DC 这长串字符串放到一起，就是 DN 了。 组织顺序 这个组织顺序是逆序的。 举例来说，下面的 DN： CN=cwikius,ou=Users,dc=jumpcloud,dc=com 实际的查找顺序是 DC=COM DC=jumpcloud OU=Users CN=cwikius 最高一级的路径在最后面，如果理解为文件系统的查找路径的话就是： COM/jumpcloud/Users/cwikius 最后的 CN=cwikius 可以理解为一个具体的文件，只是这个文件没有后缀罢了。 如上图类似的一个结构。 https://www.ossez.com/t/ldap-dn-cn-dc-ou/522
车在美国就是用来开的。 说美国人完全不贴标签也有点断章取义，开个豪车也会吸睛不少。但绝对没有我们这么疯狂。在美国不会因为你开个豪车，你就可以傲视群雄，认为所有人都应该高看你一眼。 美国人的车用途也很多，拖点东西，拉点货再平常不过了，这时候皮卡最方便，马力越大越好。最常见的应该就是福特150了。 家里有孩子的，商务车奥德赛，丰田塞纳这种上下车方便，孩子坐着舒服，空间感比较好。 美国北部下雪时间比较多，四驱很多时候是标配，安全第一。 好车保险贵，维修贵，被撞，被刮心疼，在纽约这种地方，小丰田就最方便。刮了都不心疼。 美国人也不迷信德系车，大奔照样修得不亦乐乎，还不如小丰田，好修，配件多，美国人有时候还没事喜欢自己折腾下。 美国人只是因为把车和人早就不划等号了，不怎么贴标签了，车这东西，选最合适自己的，安全第一，经济实惠就行。这就是为什么美国人对豪车也没啥情节的原因了。
光从商业来说，5G 应该有点步子太快了。要不然也不会有联通关基站一新闻了。 最开始我们应该是不希望被卡脖子，想直接上5G，我们这里有个后发优势。 就好像我们手机支付直接跳过信用卡，而上升到二维码，这不是因为我们真的有多么多么牛，只是因为我们信用卡支付和终端普及这里是空白，我们有后发优势，可以直接推倒重新选择市场和新技术。 同理的还有类似我们的宽带网络，我们可以直接上光纤，美国这边还在用同轴电缆，欧洲也好不到那里去。 我们也想在5G 这边实现这种跨越。但是受限于无线信号的特性，越高的传输速度，频率就越高，信号覆盖率越低，基站数量要求就越多。实际上应用层面这个用途还没有完全开发出来，这么高的带宽，除了视频，图片，和其他某些特定场景需要这种大数据传输来说，文本和其他状态传输，根本不需要这么高带宽。这就导致应用不足，应用不足就会导致收入下降，入不敷出就是现状了。 有些东西可以弯道超车，有些东西还真不是这样的。当然这里面利益太多，不是我们这种小屁民能掰清楚的。只是从技术层面 BB 几句而已了。
其实都差不多。 浏览器市场上就那么几家，只要网站不存在浏览器兼容的问题，那个都差不多。 我们很多网银和网站还只能用 IE 浏览器，都是老古董了。 Chrome 针对中文有一个小亮点，就是输入（）中文括号的时候，Chrome 能够帮你自动补齐另外一半，然后你的光标在括号里面。 Edge 没有这个小功能，你需要输入左右 2 个中文括号。如果你只是浏览，在浏览器里面写作的内容不多的话，这个功能可能对你也没有什么太大作用。 如果你写作或者书写量比较大的话，这个小功能也挺好用的。 https://www.ossez.com/t/edge-chrome/521
主要就是这个东西办理起来麻烦繁琐，领事馆的工作人员其实工作量也不少的，为了办一个类似证明你妈是你妈的东西，真的很闹心。 如果你住的地方离开领区比较远的话，你还要大清早去一趟，有时候还得在领馆那边找个地方过夜。如果一切顺利还能办出来还好，就怕缺材料办不了你还得回去再跑一趟。真心费时费力，麻烦得不要不要的。 留学生本来就有出入境记录，有成绩单，这些东西。其实很多学生只要是正规入学的学校都会记录，调用学生成绩单，学位证这些证明非常方便，直接给学校发个邮件就能拿出来，学生也可以做学校带有封条的成绩单。 这归国人员证明真的意义不大，不过话说回来，我们办的很多证明真的有那么大意义吗？很多东西就是跑死你不偿命的那种。 https://www.ossez.com/t/topic/520