• [技术干货] 华为云obs git hub 上的release 版本 tar.gz 包解压不出来
  • [交流分享] Git 常用命令
    基础命令初始化一个Git仓库:git init添加到暂存区:git add <file>提交到本地仓库:git commit -m <message>仓库版本号切换:git reset --hard commit_id查看提交历史:git log查看历史命令:git reflog丢弃工作区的修改:git checkout -- file添加到了暂存区,想丢弃修改:git reset HEAD <file>、`git checkout -- file`远程操作关联一个远程库:git remote add origin git@server-name:path/repo-name.git第一次推送分支的所有内容:git push -u origin branch-name之后每次提交:git push克隆远程仓库:git clone repo-address拉取远程分支的代码:git pull分支操作查看分支:git branch创建分支:git branch <name>切换分支:git checkout <name>或者git switch <name>创建+切换分支:git checkout -b <name>或者git switch -c <name>合并某分支到当前分支:git merge <name>删除分支:git branch -d <name>查看分支合并图:git log --graphstash 操作将当前修改放到堆栈中:git stash save <message> 或git stash查看 stash 了哪些存储:git stash list恢复最近一次 stash 的存储(会删除):git stash pop恢复指定的存储代码(会删除):git stash pop stash@{index}恢复最近一次 stash 的存储(不会删除):git stash apply恢复指定的存储代码(不会删除):git stash apply stash@{index}显示最近一次的 stash 的存储做了哪些改动: git stash show 显示指定的 stash 的存储做了哪些改动: git stash show stash@{index}删除指定的 stash:git stash drop stash@{index}删除所有缓存的stash:git stash cleartag 操作新建一个标签,默认为HEAD,也可以指定一个commit id:git tag <tagname>指定标签信息:git tag -a <tagname> -m "blablabla..."查看所有标签:git tag推送一个本地标签:git push origin <tagname>推送全部未推送过的本地标签:git push origin --tags删除一个本地标签:git tag -d <tagname>删除一个远程标签:git push origin :refs/tags/<tagname>从指定的标签拉取一个分支出来:git branch <new-branch-name> <tag-name>
  • [分享交流] OpenJDK 从 Mercurial 迁移到 GitHub
    摘自 https://www.oschina.net/news/117545/openjdk-github-migration 局长 发布于 2020年07月29日OpenJDK 项目正在从 Mercurial 迁移到 GitHub,预计在2020年9月完成。切换至 Git 代码版本控制系统的部分预期目的是提升性能和对代码审查的更好支持。OpenJDK 从 2008 年起一直使用 Mercurial 作为源代码管理解决方案,用于存储代码并进行代码审查。如今部分 OpenJDK 项目(如 Loom、Valhalla 和 JMC)已完全从 Mercurial 迁移至 GitHub,还有部分项目例如 JDK 本身正在迁移中,对于这些项目,其仓库已托管在 GitHub 上,但目前仍是只读副本。到 9 月份 GitHub 成为正式的读写主仓库时,JDK 项目将加入其中。OpenJDK 在 2018 年开始评估 Mercurial 在源代码管理方面的可能替代方案,当时还定义了一系列评估标准,宗旨是“提升所有贡献者(无论是新贡献者还是现有贡献者)的生产力”:性能:从主仓库进行克隆操作的时间、本地操作的时间等空间效率在不同地区的可用性支持常见的开发环境,例如 Linux, Mac 和 Windows能够轻松托管 JDK 的整个历史项目文件和未来十年基于其历史的预计增长支持通用的 JDK 代码审查实践提供程序化 API,以实现流程协助以及审查和流程的自动化尽管现有的 OpenJDK 开发者熟悉 Mercurial 以及存在一定的迁移成本,但最后还是决定将 OpenJDK 迁移至 GitHub,原因是看中了 GitHub 的性能、丰富的 API 和日渐扩大的社区环境。查看此 JEP(JEP 369: Migrate to GitHub) 了解迁移至 GitHub 的详细原因。
  • [其他] 【故障】【通信】 terminating connection due to administrator
    概要本篇主要讲解GaussDB使用过程中遇到的“FATAL:  terminating connection due to administrator command”相关报错进行阐述。按报错现象可分为两类场景,一类是在客户端报错的同时,查找cn日志相应时间点的日志,可以找到相关报错日志;另一类是客户端报错,但cn日志在报错时间点未能找到相关报错日志。接下来分别以这两种场景进行以案例的形式进行介绍介绍。(后续有其他场景或案例会持续补充更新)目录【场景一: CN在客户端报错相应时间点有日志记录】【问题描述】【分析过程】【闭环方案】【场景二: CN在客户端报错相应时间点未找到日志记录】【分析及案例】【场景一: CN在客户端报错相应时间点有日志记录】【问题描述】 业务偶现报错“FATAL:  terminating connection due to administrator command”,如下图:    【分析过程】业务报错打印“FATAL: terminating connection due to administrator command”, 经过排查代码只有在收到SIGTERM信号时打印此信息。进一步分析SIGTERM信号只有3个场景会触发:(1)集群停止shutdown;(2)强制清理连接clean connection force;(3)调用终止服务线程函数pg_terminate_backend(pid)三种场景详细分析如下:第一种情况:集群停止shutdown场景,分析全量日志,查看报错时间点是否有任何集群停止命令对应日志,若没有排除集群停止shutdown导致服务线程终止因素。# grep -nr "fast shutdown request" ./第二种情况:强制清理连接clean connection force,通过排查数据库各模块代码,在数据库内没有任何调用此接口的代码,只是一个对外接口,排除数据库内部自行调用clean触发因素。第三种情况:调用终止服务线程函数pg_terminate_backend(pid),通过排查各模块代码,数据库内部有且仅有cm_agent模块一处调用。        cm_agent在检测磁盘超过阈值(默认90%)场景下,会调用命令“select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10”终止当前CN上所有非omm用户的SQL,同时打印调用日志“cancel session ok”,排查cma日志,报错时间点是否出现过cma终止当前cn所有非omm用户sql的打印。并未发现日志打印,说明cma并没有发送终止命令。# grep "pg_terminate_backend" cm/*/*.log·   目前为止遇到的此报错大多数是由于客户端调用pg_terminate_backend和clean connection foece导致,当用户遇到此类问题时,排除集群停止shutdown导致服务线程终止因素,建议排查执行的作业是否包含pg_terminate_backend和clean connection foece关键字,以下通过两个案例简单说明。·   案例详解·         案例一:1、  报错现象:客户跑批时sql被无故杀掉,业务报错打印“FATAL: terminating connection due to administrator command”2、  在日志中查看到,有关于pg_terminate_backend调用的记录(如下图)         3、  另外,CM在检查磁盘空间超过阈值设置只读时,也会下发pg_terminate_backendBDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-26 22:12:28.502 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.  BDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-27 20:14:47.912 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.  BDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-29 04:08:51.278 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.4、  因此从日志来看,业务侧确实有调用pg_terminate_backend杀线程, 另外cm在检查磁盘空间超过阈值设置只读时也下发过几次pg_terminate_backend·         案例二:    1、报错现象:    客户端偶现报错:                2、分析    1)根据上述报错场景分析,排除集群停止shutdown,怀疑可能是调用了clean connection force和pg_terminate_backend,gdb抓现场,设置两个断点断点:pg_terminal_backend和clean_connection force。(gdb) bt #0  CleanConnection (stmt=0x7f62118aa468) at poolutils.cpp:274 #1  0x0000000001875f35 in standard_ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true,     dest=0x7f62118aa580, sentToRemote=false, completionTag=0x7f61d95648a0 "") at utility.cpp:6498 #2  0x0000000001886098 in pgaudit_ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true,     dest=0x7f62118aa580, sentToRemote=false, completionTag=0x7f61d95648a0 "") at auditfuncs.cpp:1240 #3  0x000000000186803e in ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true, dest=0x7f62118aa580,     sentToRemote=false, completionTag=0x7f61d95648a0 "") at utility.cpp:1506 #4  0x00000000018637c9 in PortalRunUtility (portal=0x7f62118af060, utilityStmt=0x7f62118aa468, isTopLevel=true, dest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1682 #5  0x0000000001863c2c in PortalRunMulti (portal=0x7f62118af060, isTopLevel=true, dest=0x7f62118aa580, altdest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1842 #6  0x0000000001862522 in PortalRun (portal=0x7f62118af060, count=9223372036854775807, isTopLevel=true, dest=0x7f62118aa580, altdest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1114 #7  0x000000000184c22b in exec_simple_query (query_string=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", messageType=QUERY_MESSAGE, msg=0x7f61d9564ba0) at postgres.cpp:2777 #8  0x0000000001857110 in PostgresMain (argc=1, argv=0x7f624818f850, dbname=0x7f62437418a8 "database_resource_monitor", username=0x7f6243741840 "user_resource_monitor") at postgres.cpp:8268 #9  0x000000000166bcd3 in BackendRun (port=0x7f61d95661c0) at postmaster.cpp:7063 #10 0x000000000166d743 in SubPostmasterMain (argc=3, argv=0x7f61d9566430) at postmaster.cpp:7810 #11 0x000000000166c8f7 in MainStarterThreadFunc (args=0x7f625ad01bd8) at postmaster.cpp:7250 #12 0x0000000001d67ae6 in ThreadStarterFunc (arg=0x7f625ad01bc0) at gs_thread.cpp:389 #13 0x00007f633bf97806 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f633bcf264d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) p *MyProcPort $1 = {sock = 212, …, remote_host = 0x7f2e6074aee0 "100.185.178.233", remote_hostname = 0x7f2e6074aee0 "100.185.178.233", remote_hostname_resolv = 0, remote_port = 0x7f2e6074af70 "52563", …}    2)由上知,对端100.185.178.233,端口41684 ,明确对端信息后,登录到对端查看此连接对应的对端进程到底在做什么    3)登录到对端机器100.185.178.233,根据remote_port 52563找到进程,结果如下图:    linux178233:/lvs_kehuduan/script/dml # netstat -anop | grep 52563    tcp        0      0 100.185.178.233:52563   100.185.185.182:6000    ESTABLISHED 229505/gsql         keepalive (1.40/0/0)    linux178233:/lvs_kehuduan/script/dml # ps ux | grep 229505    root     229505  0.7  0.0  53048  3400 pts/1    S    22:07   0:00 gsql -d database_resource_monitor -p 6000 -U user_resource_monitor -W           -h 100.185.185.182 -f dml/test_clean_connection.sql    root     229531  0.0  0.0   5736   816 pts/4    S+   22:08   0:00 grep 229505    linux178233:/lvs_kehuduan/script/dml #        3、结论    最终发现是用户在100.185.178.233 上通过gsql连接到集群,并持续执行test_clean_connection.sql,就是下图一个神奇的脚本,接近无限循环清理连接。。    一直在执行test_clean_connection.sql:--创建jack用户。 CREATE USER jack PASSWORD 'Bigdata123@'; --删除数据库template1在dn1和dn2节点上的连接。 CLEAN CONNECTION TO NODE (dn_6001_6002) FOR DATABASE template1; --删除用户jack在dn1节点上的连接。 CLEAN CONNECTION TO NODE (dn_6001_6002) TO USER jack; --删除在数据库postgres上的所有连接。 CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres; --删除用户jack。 DROP USER jack;案例三:    1.客户业务从172节点的cn接入    2.用户业务偶现报错打印“FATAL: terminating connection due to administrator command“,重试可成功    2.根据以上报错场景分析,排除shutdown场景,此报错只有两种场景:1)外部调用pg_terminate_backend函数 2)clean connection force    3.排查发现用户自己有杀超时语句的程序,但是在172节点客户程序的日志中未找到该语句被杀的记录,并且语句是刚跑起来就被杀    4.继续排查,在171节点的客户程序日志中找到了该语句被杀的日志    5.经分析,是因为客户杀语句的程序使用了current_time() - backend_start【闭环方案】    排查代码中下发SIGTERM信号场景,后续版本中在调用pg_terminate_backend和clean connection force时,均打印日志,例如:    Send SIGTERM to thread:    send SIGTERM signal to walreceiver thread    use pg_terminate_backend to terminate backend thread,tid【场景二: CN在客户端报错相应时间点未找到日志记录】    【分析及案例】    1、报错现象    Jdbc客户端报错如下:        2、分析    1)CN和DN日志中均未搜到“FATAL: terminating connection …”报错信息。按照场景一种提到的三种方式排查,均为发现异常。    2)查看用户设置的session_timeout为1d,当达到超时时间时,集群会自动关闭此连接,如下图,在11:24时重新执行作业报错,查看日志发现在11:18:54.387因为已经达到超时时间,连接已经被关闭。        3、对于jdbc来说,客户端和cn的之间的连接达到了session_timeout被kill,但是getConnections又从jdbc连接池拿了这个连接所以报的错。
  • 从git import项目的时候,如何只导入指定文件,而不是把整个项目导进去
    从git import项目的时候,如何只导入指定文件,而不是把整个项目导进去
  • git提交如何忽略class文件呢
  • [技术干货] DevOps on DevCloud| DevOps上华为云DevCloud“六步走”实践
    引言:在“DevOps能力之屋(CapabilitiesHouse of DevOps)”中,华为云DevCloud提出(工程方法+最佳实践+生态)×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列,针对DevOps领域场景,阐述该场景在华为云DevCloud上的实施方法与实践。本文阐述了企业A在实施DevOps过程中,如何一步步采用华为云DevOps平台。此客户故事,希望为采用DevOps平台的企业提供借鉴。为行文阅读,本文中企业A将以第一人称(“我”或者“我们”)来进行阐述。目前,在产品团队的不断努力下,从第一次接触华为云DevCloud开始,现在我们终于拥有了优雅、全面的一站式DevOps解决方案,团队成员不必再费心劳力地使用和维护多种工具及版本。然而回首过去,我们的DevOps持续交付流水线,就像大多数公司和开源项目一样,有很多混杂的产品、服务和脚本,都松松散散勉强一起使用。同时来自不同公司的不同DevOps工具并不总是能够很好地兼容,情况越发复杂。简而言之,我们有很多工作要做,但最终,我们决定要统一工具的行为和目标。采用华为云DevCloud,我们经历了6个关键阶段。我们希望这会给通往DevOps涅槃路上的企业提供帮助。第一步:找到你的痛点也许,对于大多数的企业,包括我们自己,DevOps转型的最大动力往往来自于“火烧屁股”,主动转型多数时候是奢谈。正如微软Donovan Brown在谈论到DevOps时经常说:“找到最伤人的东西,围绕它去做很多很多的事儿,使它越来越好,直到它不再伤人。”这也成为我们的座右铭。如果你打算采用DevOps,并且正在考虑使用DevCloud,那么首先审视一下自己:在我们的DevOps流水线中,最痛苦的事情是什么?没有足够的单元测试?部署新版本太多手工操作导致容易出错?即使你已经到达了DevOps的顶峰,即使你的发布是可以一键部署,你仍然可能在生产中中断某件事情。然而,你会发现你没有合适的工具来告诉你错在哪里;也许是某些事情遇到了瓶颈,或者只是没有按预期的方式工作。因此,让我们找出这些痛点并从那里开始。   第二步:源代码版本控制 “代码”作为软件研发的核心产物,因而源代码版本控制是DevOps的基石。在DevOps异地协同上,集中式的SVN远不如分布式Git,因此,很多公司(包括我们自己)将代码从SVN迁移到Git上。这样,你可以使用华为云DevCloud的代码托管服务。华为云DevCloud也提供了迁移指南通过工具或者脚本来帮助企业进行迁移,大大简化了相关工作。当然,如果你采用Git,应该充分意识:No Pains,No Gains。对于新手来讲,Git需要一个巨大的学习曲线,合并、推送、拉取,变基等很多操作有一点儿复杂。这儿有一个很好的建议,当你开始使用Git时,可以像对待以前的版本管理系统一样对待它,如果你把你所知道的相关知识转义一下应用到Git上,你就可以摆脱初始学习的困境了。对于其他复杂的操作,随着时间的推移,你将开始适应它,水到渠成地学会使用那些强大的功能。现在整个行业最近都在迅速采用Git,但愿你不会迟到。Git有一个真正具有变革意义的杀手级功能——轻量级分支。Git创建分支的本质只是只是创建一个指针。当然选用哪种分支模型(GitFlow、Gitlab Flow、GitHub Flow或者自定义flow),产品团队需要考虑团队生产力和个人生产力之间的平衡。建议从成熟的flow模型开始。第三步:任务管理任务管理是产品团队除了源代码版本控制外必须做好另一个基础工作。我们一直在使用业界某主流敏捷项目管理工具T。我们非常喜欢它的简单,在看板的工作跟踪时,只有“未完成”、“进行中”、“已完成”等3个状态。但是随着研发需求的增加,简单的状态跟踪无法满足我的需求。此外,我在拿到客户需求的初期,希望对产品做一个需求规划,让团队可以按照发布或迭代进行需求拆解。DevCloud的项目管理服务解决了这些痛点,例如思维导图可视化按层级进行需求规划、标准的Scrum方法、可以自定义工作项状态。当然这意味着你失去了简单明了的方式。归根结底,你可以选择你钟爱的工具,例如至为简洁的敏捷项目管理工具T,它可以工作得很好,但是你将丢失可追溯性。而华为云DevCloud可以帮你在DevOps方面做得更多,例如需求工作项与代码提交的关联,需求工作项与测试用例和缺陷的关联等。第四步:拥抱CI/CD在使用华为云DevCloud前,我们使用的是某主流工具C。它实际上是一个非常好的持续集成产品,它提供On Premises与SaaS版本。使用DevCloud编译构建服务的一个好处是构建启动的速度变得飞快。对于工具C,每当我们需要一个新的构建时,就会提供一个VM,这可能需要5到10分钟。这个前置时间太久,变得很烦人。而华为云DevCloud拥有了一个热的、随时可以在云中构建的机器池,所以只要有人提交一个新的提交,构建就会立即发生。以前,我们的部署过程是手动的,我们需要运行一堆批处理脚本。而使用DevCloud流水线是一种乐趣,它不仅仅可以支持一键全自动部署,将变更投入生产,而且提供了完美的可视化编排,可以将构建、部署、自动化测试等纳管起来,并根据实际需要定制多级流水线,加入质量门禁、人工审核等控制。第五步:Bug跟踪在此之前,我们使用Excel对Bug进行跟踪,随着团队人数的增加,分清Excel版本已经足够让我们头疼了。使用了DevCloud之后,简直给我们的工作带来了不可思议的改变。首先,Bug跟踪在早例会的直观展示。当我们开早会时,将Scrum缺陷跟踪板投屏,可以通过过滤筛选每个成员手中的Bug状态和等级,便于识别风险。其次,Bug跟踪与需求、测试的关联。DevCloud中基于需求创建测试用例,测试用例失败生产Bug,实现了需求-测试用例-缺陷双向关联。最后,多维度的Bug统计。在DevCloud统计报表中,预置了多种Bug统计报表,用户也可以根据自己的需要自定义统计报表。第六步:定制DevCloud适应项目需求不要陷入DevCloud希望你工作的方式中。如果有众多不同的状态,比如批准、已提交、已解决、已验证,请不要盲目屈从于产品对敏捷或Scrum的定义或者那些对你不起作用的东西。先问问自己什么是可能起作用的最简单的事情,然后在DevCloud上开展工作。最为重要的是,不要因为DevCloud产品经理想的太多而强迫自己过度思考,无所适从。自定义相对比较简单,因为DevCloud提供了工作项字段、模板、状态流转等的可定制性。你可以用它来增加东西,但你也可以用它来减轻东西。所以,把对你没有意义的东西拿走,只保持最低限度。你只需把它作为一个工具来了解你的团队在做什么,并传达优先事项,保持它的简洁与实用。采用华为云DevCloud最重要的是,它作为一个全面的解决方案所带来的聚集效应。你可以选择只使用其中的部分服务,然而如果你选择使用尽可能多的服务,你将发现令人震惊的积极变化。当然,这并非没有困难,一蹴而就。DevOps转型面临不同层面的变革,从改变企业文化,到整个组织的新的工具平台的投资,到团队成员的知识与技能水平。但请相信,这确实是一个短期痛苦、长期收益的改变!全面的解决方案无疑会是一个赢家。一旦我们采用了一体化工具平台,向我们的客户交付软件就变得更容易、更自动化,甚至是一个很好的体验。无论如何,采用华为云DevCloud会失去什么呢?我相信无论只使用部分服务,还是全部服务,它只会给你带来更多的业务效益,以及高效的交付体验。
  • 鲲鹏920 acl-3.5.0编译指南for centos7.6 ★★★
    1 介绍简要介绍acl 工程是一个跨平台(支持LINUX,WIN32,Solaris,MacOS,FreeBSD)的网络通信库及服务器编程框架,同时提供更多的实用功能库。通过该库,用户可以非常容易地编写支持多种模式(多线程、多进程、非阻塞、触发器、UDP方式、协程方式)的服务器程序,WEB 应用程序,数据库应用程序。此外,该库还提供了常见应用的客户端通信库(如:HTTP、SMTP、ICMP、redis、memcache、beanstalk、handler socket),常见流式编解码库:XML/JSON/MIME/BASE64/UUCODE/QPCODE/RFC2047 etc。本工程主要包含 7 个库及大量示例。说明如下:1.     lib_acl: 该库是最基础的库,其它 4 个库均依赖于该库; 该库以 C 语言实现。2.     lib_protocol: 该库主要实现了 http 协议及 icmp/ping 协议; 该库以 C 语言实现。3.     lib_acl_cpp: 该库用 C++ 语言封装了 lib_acl/lib_protocol 两个库,同时增加了一些其它有价值的功能应用。4.     lib_fiber: 该库为支持协程库,直接 hook 系统 read/write 等 API,与 epoll 配合支持高并发网络编程。5.     lib_dict: 该库主要实现了 KEY-VALUE 的字典式存储库,该库另外还依赖于 BDB, CDB 以及 tokyocabinet 库。6.     lib_tls: 该库封装了 openssl 库,使 lib_acl 的通信模式可以支持 ssl。7.     lib_rpc:封装了 Google 的 protobuf 的库。目前用的最多还是 lib_acl 、lib_protocol 以及 lib_acl_cpp三个库。详细的acl介绍可以查看:https://github.com/acl-dev/acl/或https://www.iteye.com/blog/zsxxsz-576517建议的版本根据实际需要使用即可。本次移植的是acl3.5.0版本。2 环境要求项目版本下载地址CentOS7.6https://www.centos.org/download/Kernel4.14.0包含在操作系统镜像中。Gcc4.8.5或者7.3.0均可 3 配置编译环境要有gcc/g++编译器及 gnu make4 获取源码                                          步骤 1      下载acl3.5.0源码。下载地址:https://github.com/acl-dev/acl/archive/v3.5.0.tar.gz                                          步骤 2      复制至服务器自定义目录如/home/test/下。5 编译与安装提供以下3种编译库的方法,选其中一种编译即可。5.1 编译成单一库步骤1 进入自定义下载源码。#wget https://github.com/acl-dev/acl/archive/v3.5.0.tar.gz步骤2解压#tar -zxvf v3.5.0.tar.gz步骤3 进入解压后的acl目录。#cd acl-3.5.0步骤4 生成统一库:libacl_all.a 及 libacl_all.so,该库包含了 libacl,lib_protocol,lib_acl_cpp 三个库#make build_one 5.2 使用cmake编译库步骤1、步骤2和步骤3同上步骤4 进入build目录。        #cd build步骤5 cmake编译              #cmake ..步骤6 make完成编译              #make5.3 逐个编译静态库和动态库5.3.1 编译静态库步骤1、步骤2和步骤3同上步骤4 编译 libacl.a 库,进入lib_acl直接运行make,在lib目录生成libacl.a               #cd lib_acl               #make步骤5编译 libprotocol.a 库,进入lib_protocol 目录直接运行make,在 lib 目录下生成 lib_protocol.a             #cd ..             #cd lib_protocol             #make步骤6 编译 libacl_cpp.a 库,进入 lib_acl_cpp 目录直接运行 make static,在lib 目录下生成 libacl_cpp.a             #cd ..             #cd lib_acl_app             #make static5.3.2 编译动态库编译 libacl.so, libprotocol.so, libacl_cpp.so 的方式与编译静态库的方式有所不同,需要分别进入三个目录执行: make shared rpath=${lib_path},其中 shared 表示需要编译动态库,${lib_path} 需要用实际的目标路径替换,比如:make shared rpath=/opt/acl/lib,则会将动态库编译好后存放于 /opt/acl/lib 目录,编译这三个库的顺序为:libacl.so --> libprotocol.so --> libacl_cpp.so。步骤1、步骤2和步骤3同上步骤4 首先编译libacl.so       #cd lib_acl       #make shared rpath=/opt/acl/lib      //根据实际动态库的存放路径修改步骤5 编译libprotocol.so      #cd .. #cd lib_protocol      #make shared rpath=/opt/acl/lib步骤5 编译libacl_cpp.so      #cd .. #cd lib_acl_app      #make shared rpath=/opt/acl/lib最后检查是否都已经有编译出来的库文件6 参考资料https://www.iteye.com/blog/zsxxsz-1506554 
  • [技术干货] 快速上手华为云DevCloud
    本节为您介绍软件开发平台(DevCloud)的基本操作流程,帮助您快速上手DevCloud。注册账号访问官网,单击页面右上角“注册”。https://www.huaweicloud.com/根据界面提示填写信息并完成注册。已完成注册的账号即为企业管理员。更详细操作指导请参考账号中心-账号注册。https://support.huaweicloud.com/usermanual-account/zh-cn_topic_0069252244.html实名认证账号注册完成后,需要进行实名认证,才能够正常使用DevCloud。实名认证分为以下两种:个人实名认证https://support.huaweicloud.com/usermanual-account/zh-cn_topic_0077914254.html企业实名认证https://support.huaweicloud.com/usermanual-account/zh-cn_topic_0077914253.html配置项目创建项目登录DevCloud,单击“新建项目”。https://auth.huaweicloud.com/authui/login.html?service=https%3A%2F%2Fdevcloudsso.huaweicloud.com%2Fauthticket%3Fservice%3Dhttps%253A%252F%252Fdevcloud.cn-north-4.huaweicloud.com%252Fhome选择项目类型(“Scrum”或“看板”),输入项目名称和项目描述,单击“确定”,完成项目的创建。添加项目成员手动添加项目成员通过二维码邀请项目成员在DevCloud首页单击项目名称进入项目详情。单击导航栏“设置 > 通用设置 > 成员管理”,进入“成员管理”页面。DevCloud提供两种添加项目成员的方式:项目管理服务更多操作请参见项目管理-用户指南。配置代码仓库安装Git客户端通过Git官网下载安装包,并使用默认配置安装Git客户端到本地电脑。运行Git Bash,Git Bash中输入以下命令行配置用户名和邮箱。git config  --global user.name  git config  --global user.email         3. 输入以下命令行,生成一对SSH密钥。ssh-keygen -t rsa -C "<您的邮箱>"创建代码仓库单击页面上方菜单“代码 > 代码托管”,进入“代码托管”页面。根据需要选择“普通新建”、“按模板新建”或“导入外部仓库”。根据页面信息填写仓库名称等基本信息,单击“确定”完成代码仓库的创建。单击仓库名称,进入代码仓库,即可查看仓库内的文件详情。克隆/推送代码单击“设置我的SSH密钥”,进入“SSH密钥管理”页面。单击“添加SSH密钥”,输入标题,并将在步骤•安装Git客户端中生成的密钥,单击“确定”完成添加。返回仓库列表,单击“克隆/下载”,复制仓库地址。运行Git Bash,输入以下命令行,克隆云端仓库到本地。git clone <您仓库的SSH下载链接>       3. 在本地完成代码的编辑后,在Git Bash中输入以下命令行,保存代码并推送到代码仓库。git add . git commit -m  git push origin master4. 返回代码托管服务,单击代码仓库名称,即可查看代码仓库中的文件。代码托管服务更多操作请参见代码托管-用户指南。配置流水线创建代码检查任务代码检查服务更多操作请参考代码检查-用户指南。单击导航栏“代码 > 代码检查”,进入“代码检查”页面。单击“新建任务”,选择需要检查的代码仓库,单击仓库名称后的“创建”,完成代码检查任务的创建。单击任务名称,进入“代码检查详情”页面,单击“开始检查”启动任务。任务执行成功后,即可查看代码问题列表。创建编译构建任务编译构建服务更多操作指导请参考编译构建-用户指南。单击导航栏“构建&发布 > 编译构建”,进入“编译构建”页面。单击“新建任务”,输入任务名称,单击“下一步”。选择源码源、源码仓库、分支,单击“下一步”。根据需要选择构建模板,单击“确定”,进入“构建步骤”页面。根据需要增、删并编辑构建步骤,单击“新建”,完成任务的构建。单击任务名称,进入“编译详情”页面,单击“执行启动”启动任务。任务执行成功后,可以在页面中查看构建日志,也可以到发布服务中查找生成的软件包。创建部署任务部署服务更多操作指导请参考部署-用户指南。单击导航栏“设置 > 通用设置”,找到“主机组管理”页面,添加主机组与授信主机。单击导航栏“构建&发布 > 部署”,进入“部署”页面。单击“新建任务”,输入任务名称、描述,单击“下一步”。根据需要选择部署模板,单击“确定”,进入“部署步骤”页面。根据需要配置部署步骤,并填写相应步骤所需信息,单击“保存”,完成任务的创建。单击任务名称,进入“部署详情”页面,单击“执行启动”启动任务。任务执行成功后,可以在页面中查看部署日志,也可以登录主机查看部署结果。配置流水线流水线服务更多操作指导请参考流水线-用户指南。单击导航栏“构建&发布 > 流水线”,进入“流水线”页面。单击“新建流水线”,输入流水线名称,单击“下一步”。根据需要选择流水线模板,单击“下一步”。选择代码源、源码仓库,单击“下一步”。根据需要配置代码检查、编译构建、部署等阶段,添加相应任务,单击“保存”,完成流水线的创建。单击任务名称,进入“流水线详情”页面,单击“全新执行”启动任务。待任务执行成功后,可单击各任务查看其详情。
  • [技术干货] window下搭建kafka运行环境
    背景Kafka作为流式处理的消息中间件,应用场景极其广泛。那么在使用过程中,遇到不明所以的报错信息,无法很好的定位问题根因。此时,若本地有一个套kafka的运行环境,就可以进行本地代码调试。一方面,能够快速定位问题根因;另一方面,通过调试kafka源码,可以很好地熟悉kafka代码背后的原理。因此,一套本地kafka运行环境对kafka运维人员是必不可少的。搭建流程 搭建步骤软件版本:jdk1.8.xscala:2.11.12gradle:3.1zookeeper:3.5.1kafka:1.1.0环境:windows单机,一个zookeeper实例,一个kafka实例一、      安装前准备1.    安装jdk去JDK官网下载jdk,然后在window上安装,此处略。2.    安装scala从Scala官网地址http://www.scala-lang.org/download/下载Scala的windows安装包,验证:3.    安装gradle从gradle官网https://gradle.org/releases/下载gradle安装包,如下图所示安装完毕后,验证: 二、      安装启动zookeeper1.    下载安装包此处直接去官网下载,使用的是 zookeeper-3.5.1-alpha,解压后zookeeper家目录记为{zookeeperHome}变量2.    修改配置a)         打开{zookeeperHome}\conf,复制zoo_sample.cfg重命名成zoo.cfgb)         编辑zoo.cfg,修改dataDir为【dataDir=/zookeeper-3.5.2-alpha/data】,样例如下 tickTime=2000initLimit=10syncLimit=5dataDir=\datadataLogDir=\logclientPort=2181server.1=localhost:2287:3387同时,在dataDir目录下新建myid文件,传入一个整数值c)         添加环境变量   ZOOKEEPER_HOME          {zookeeperHome}   Path 在现有的值后面添加     ;%ZOOKEEPER_HOME%\bin; 3.    启动zookeeper打开cmd,切换到bin目录下,执行(该cmd窗口不能关闭)zkServer.cmd 若显示 JAVA_HOME is incorrectly set,则 {zookeeperHome}\bin目录下的zkEnv.cmd中第一行添加set JAVA_HOME="C:\Program Files\Java\jdk1.8.0_131" 三、      安装启动kafka1.    下载安装包下载源码包(去kafka官网下载)在build.gradle中增加国内maven库2.    修改配置a)         解压后,执行: b)   修改server.properties修改log.dirs为本地目录地址 3.    启动kafka 方式一:idea上调试  方式二:cmd启动i.      打开cmd,切换到kafka家目录C:\kafka-1.1.1-src>ii.      输入gradle命令,执行C:\kafka-1.1.1-src>gradleiii.      执行完成后,执行以下命令C:\kafka-1.1.1-src>gradlew jariv.      启动kafkaC:\kafka-1.1.1-src>.\bin\windows\kafka-server-start.bat .\config\server.properties附录安装过程采坑指南:1,直接点击运行,可能出现问题:java.lang.NoClassDefFoundError: org/apache/log4j/or/RendererMap添加slf4j.jar和log4j.jar添加到classpath: 
  • 【操作指南系列】CloudIDE实例中导入Git代码库
    CloudIDE中导入Git代码库这几天有不少同学在问关于Git代码仓库导入的问题,本着对开发者负责的态度(尤其是刚刚爱上开发的小伙伴们),给大家集中回答一下这几个问题,并且总结一下Git仓库导入CloudIDE实例的基本操作。问:免费体验试用能不能保存代码?答:免费体验实例没提供云硬盘来保存数据,但是Git相关操作是支持的,我个人鼓励软件配置管理活动。问:免费体验试用实例怎么切换项目?答:可以更换仓库,但是实例启动前只能指定公开仓库,如果尝试私有实例的话,那先启动实例然后往后读。问:CloudIDE仅在北京四开区,其他区怎么使用?答:CloudIDE实例内有互联网访问通道,可访问任意区域的Codehub代码库,也可访问GitHub或Gitee等其他仓库,公开和私有仓库均可。建议开通CloudIDE服务并使用鲲鹏免费实例仔细体验。问:使用Codehub+CloudIDE工作的正确姿势是啥?答:看你以什么目的来使用CloudIDE,①随便看看,使用免费体验;②能力验证,创建CloudIDE私有实例,然后看本文后面部分;③工作交付,在Codehub创建项目代码库,创建CloudIDE私有实例,导入代码开发。下面是正文,给大家讲一下如何在CloudIDE中导入Git代码库。1、客户端访问Git代码库的两种方式对于代码仓库而言,CloudIDE实例就是一个位于云端的“客户端”,那么访问Git仓库的方式就是两种,一种是通过SSH认证方式,一种是通过HTTPS认证方式。(还有一些其他方式属于扩展话题暂时不讨论)CloudIDE通过SSH方式访问代码仓库的原理示意图如下所示。简单来说,就是用户先用自己的私有信息生成一个公钥+私钥对儿,然后呢把公钥保存在代码托管(Git)平台上,私钥自己拿着。每次从客户端访问代码仓库的时候送私钥过去认证一下,通过了就可以下载代码到客户端(图中是CloudIDE实例中)了。CloudIDE通过HTTPS方式访问代码仓库的原理示意图如下所示。简单来说,就是用户把访问私有代码仓库的用户名和密码先预置在代码托管(Git)平台上,当然了,用户自己会记住。每次从客户端访问代码仓库的时候,把用户名和密码送过去认证一下,通过了就可以下载代码到客户端(图中是CloudIDE实例中)了。那可能有人问了,看起来https方式更简单啊,不需要去预置Public Key,而且访问代码仓库的用户名和密码一般就是注册代码托管平台的账号,岂不是很简单?其实呢,两种方式没有优劣之别,适用的场景可能略有差异:SSH方式,秘钥记忆起来虽然不方便(完全没法记忆),但是对于需要做“体验打通整合的IDE与代码库“来说,那是良配。用户不需要再输入用户名和密码,平台间可以通过API后台打通”预置公钥“这个操作,实现一键式代码访问。而且,采用秘钥的方式,也可以根据多种秘钥不同,给予不同的代码读写权限,对持续集成和持续交付(CI/CD)领域的构建和部署来说足够安全。HTTP方式,用户可以随时访问代码仓库,简单好记忆。缺点就是每次你得输入一下用户名和密码,不利用系统间一致体验的构建(因为CloudIDE这边不方便记录你的用户名和密码啦)。所以这两种访问Git代码仓库的方式长期并存,无优劣之别。从CloudIDE实例内部导入Git仓库代码,两种方式都是支持的。2、CloudIDE实例内通过HTTPS方式访问Git代码库先说在华为云CloudIDE实例内,怎么通过https方式导入Git代码库,以华为云Codehub服务为例。第一步,预置一下代码托管平台访问的用户名和密码,正常情况下注册账号的时候都已经设置好了,可以检查一下,如下图:第二步,到CloudIDE服务去创建一个私有实例,可以不选择初始化工程(使用空白实例)。CloudIDE服务开通后,不使用不收费;使用基于鲲鹏的实例免费(2020年)。如下图:第三步,拿到HTTPS方式访问代码仓库的链接地址,如下图:第四步,从CloudIDE实例的菜单选择 “File - Import Project”,把仓库地址 “https://。。。。” 粘贴进去,再点 ”Import“ 按钮,即可完成代码库导入。如下图:第五步,(备选)如果没有导入成功,那么也可以通过从菜单 ” Terminal - New Terminal“ 打开一个新的命令行终端,利用执行Git命令这种方式来导入代码库,如下:$ git clone https://codehub.devcloud.cn-north-4.huaweicloud.com/abcdefs.git当然,你可能会被要求输入你的用户名和密码。3、CloudIDE实例内通过SSH方式访问Git代码库再说在华为云CloudIDE实例内,怎么通过SSH方式导入Git代码库,还是以华为云Codehub服务为例。第一步,生成个人的公私秘钥对。CloudIDE实例在创建的时候应自动为你生成了秘钥对,你可以在以下目录去找到他们:当然你也可以按自己的意愿重用已有的或者重新生成秘钥对。新生成秘钥对需要找到一个Git客户端窗口(Git Bash或Linux命令行)执行以下命令:$ ssh-keygen -t rsa -C "<您的密钥注释>"可以参考Codehub帮助文档关于 设置SSH秘钥 的说明。第二步,预存个人公钥到代码托管(Git)平台。为了让用户打开Codehub代码仓库更顺畅,CloudIDE服务在实例创建时,会把你的秘钥对中的公钥(pub key)从后台设置到同区域的Codehub服务上去。原则上如果你使用了本区的CloudIDE服务去打开本区域的代码仓库,是不需要去设置SSH秘钥的。当然你可以到代码 托管平台上去检查一下,如下图:重要:访问跨区的Codehub代码库,或者其他第三方Git平台(比如github或者gitee),则需要手工去设置一下公钥。方式如下:(1)打开一个CloudIDE的命令行(Terminal - New Terminal),执行以下命令:$ cd /home/user/.ssh$ cat id_rsa.pub然后把看到的公钥(pub key)内容复制到剪贴板。(2)到对应的代码托管(Git)平台,去粘贴设置公钥,如下:(Codehub例子)(码云Gitee例子)(github例子)第三步,到CloudIDE服务去创建一个私有实例,可以不选择初始化工程(使用空白实例)。CloudIDE服务开通后,不使用不收费;使用基于鲲鹏的实例免费(2020年)。如下图:第四步,拿到通过SSH方式访问代码库的链接,如下图:第五步,从CloudIDE实例的菜单选择 “File - Import Project”,把仓库地址 “git@。。。。” 粘贴进去,再点 ”Import“ 按钮,即可完成代码库导入。如下图:第六步,(备选)如果没有导入成功,那么也可以通过从菜单 ” Terminal - New Terminal“ 打开一个新的命令行终端,利用执行Git命令这种方式来导入代码库,如下:$ git clone <your-git-url-by-ssh>当然,你的私钥文件(id_rsa)得在你的缺省目录里面(/home/user/.ssh)。4、CloudIDE跨区访问Codehub代码仓库简单来说,由于用户访问token不能跨区传输,对于CloudIDE服务而言,位于其他区域的Codehub代码托管服务和第三方代码托管服务(如Github、Gitee等)没有本质的差别。首先,好消息是你的CloudIDE实例创建的时候就把SSH秘钥对帮你生成好了,并且放在了指定位置(看上面的内容);其次,坏消息是你得自己到跨区的Codehub上去把自己的Public Key给置上去(也看上面的内容)。当然,有些情况下CloudIDE服务会在后台帮你把这个事给做了。如果没做,那你自己配一下吧。第三,每一个CloudIDE的实例都带有互联网访问通道(所以你知道除了CPU和内存、硬盘之外,还有些资源的占用是你没意识到的),所以只要保证你想访问的Git代码托管平台可以从互联网访问到,就可以了。当然如果你愿意在CloudIDE的实例内安装VPN访问你的特定服务器并且可以调通的话,我也不会反对。5、关于Git操作和Git代码托管平台Git命令有上百个,平常我们常用的其实不多,下面一张图基本就说明了在CloudIDE实例内部使用Git和云端代码仓库之间的操作和关系:(原图出处:https://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html)关于Git代码托管平台,内容广泛篇幅太大,建议去看Codehub服务的帮助中心。至此,希望你对CloudIDE导入Git代码库有所了解,且对你使用CloudIDE做云上开发有所助益。祝你工作愉快!
  • [技术干货] DevOps on DevCloud|如何使用DevCloud践行GitFlow模型
    请转场https://bbs.huaweicloud.com/blogs/163315
  • [内容拦截申诉] 移植LiteOS时,在GitHub下载源码时,是下载develop分支还是dev-deserted分支?帖子误拦截,请通过,谢谢
    发文的版块名:热门技术领域-IoT物联网-小熊派发文的标题名:【论坛】[技术探讨]移植LiteOS时,在GitHub下载源码时,是下载develop分支还是dev-deserted分支?帖子内容链接:https://bbs.huaweicloud.com/forum/thread-48559-1-1.html
  • [技术干货] DevOps on DevCloud|如何多账号使用Git访问CodeHub代码库
    详情请见https://bbs.huaweicloud.com/blogs/155000
  • rocksdbjni-5.7.3.jar移植指南
    1 编译环境准备1.1 安装Openjdk下载并安装到指定目录(如/opt/tools/installed):wget  https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u191-b12/OpenJDK8U-jdk_aarch64_linux_hotspot_8u191b12.tar.gztar   -zxf OpenJDK8U-jdk_aarch64_linux_hotspot_8u191b12.tar.gzmv jdk8u191-b12   /opt/tools/installed/配置java环境变量,在/etc/profile文件末尾处增加下面的代码:JAVA_HOME=/opt/tools/installed/jdk8u191-b12PATH=$JAVA_HOME/bin:$PATHexport   JAVA_HOME PATH运行下面命令,使修改的环境变量生效:source   /etc/profile1.2 安装Maven下载并安装到指定目录(如/opt/tools/installed):wget   https://archive.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gztar   -zxf apache-maven-3.5.4-bin.tar.gzmv   apache-maven-3.5.4 /opt/tools/installed/修改maven环境变量,在/etc/profile文件末尾增加下面高亮代码:JAVA_HOME=/opt/tools/installed/jdk8u191-b12MAVEN_HOME=/opt/tools/installed/apache-maven-3.5.4PATH=$MAVEN_HOME/bin:$JAVA_HOME/bin:$PATHexport   MAVEN_HOME   JAVA_HOME PATH运行下面的命令,是修改的环境变量生效:source   /etc/profile1.3 安装Gcc等依赖项挂载OS镜像:mount   YOUR_OS.iso /media -o loop修改/etc/yum.repos.d/Base.repo文件,配置yum本地源:[Local]name=CentOS-7.4   Localbaseurl=file:///media/enabled=1gpgcheck=0运行下面的命令,使yum源配置生效:yum   clean allyum   makecacheyum安装GCC等相关依赖:yum   install git gcc gcc-c++ make cmake libtool autoconf automake -y1.4 解决-fsigned-char问题1.使用command -v gcc命令寻找gcc所在路径(一般位于/usr/bin/gcc)2.更改gcc的名字(比如改成gcc-impl)3.在gcc所在目录执行vim gcc,并填入如下内容保存:#!   /bin/sh/usr/bin/gcc-impl   -fsigned-char “$@”4.执行chmod +x gcc给脚本添加执行权限5.使用与1-4步相似的方式给g++创建同名字的脚本文件2 组件编译安装下载rocksdbjni-5.7.3源码,并解压wget   https://codeload.github.com/facebook/rocksdb/zip/v5.7.3unzip v5.7.3cd rocksdb-5.7.3修改Makefile,将DEBUG_LEVEL设为0编译打包,rocksdbjni-5.7.3-linux64.jar在rocksdb-5.7.3/java/target目录PORTABLE=1   make rocksdbjava -j83 测试无4 FAQQ: 为何编译好的jar包大小比从Maven仓库下载的大?A: Jar包内的librocksdbjni-linux64.so包含符号信息,可通过strip命令去掉。Q: 提示找不到jni.h或者jni_md.h?A: 将编译使用的JDK中的jni.h和jni_md.h移动到编译根目录。 Q:编译时报错:A: 使用以下编译命令进行编译PORTABLE=1 make   rocksdbjava -j8Q:编译时出现错误:va_list不能与nullptr进行比较A:注释掉java/rocksjni/loggerjnicallback.cc的151行,重新编译Q:遇到找不到jni.h的问题是因为没有配置JAVA_HOME路径,需要配置再次编如果还出错,则将编译使用的JDK中的jni.h和jni_md.h移动到编译根目录。
总条数:361 到第 页
上滑加载中