在IT行业中,持续集成与持续部署(CI/CD)是软件开发流程中不可或缺的一部分,而Jenkins作为一款广泛应用的开源持续集成工具,扮演着至关重要的角色。本文将详细讲解如何在无网络或内网环境下,利用提供的压缩包文件,搭建Jenkins 2.414版本,并安装包括maven、Java、vue、git在内的所有必需插件。 我们需要理解Jenkins的基本概念。Jenkins是一个用Java编写的自动化服务器,支持各种构建、部署和测试任务。它允许开发者通过配置工作流来自动化代码的构建、测试和发布过程,从而提高效率并减少错误。 在没有互联网连接或内网环境中,我们无法直接通过Jenkins的在线更新功能获取和安装插件。因此,我们需要提前下载所需的插件并离线安装。在这个特定的情况下,已经提供了一个名为"plugins"的压缩包,包含了所有需要的插件。 以下是搭建和安装插件的步骤: 1. **下载Jenkins二进制包**:从Jenkins官方网站下载对应版本(2.414)的Jenkins二进制文件,这通常是一个war文件。在无网络环境内,你需要提前将这个war文件传输到服务器上。 2. **解压Jenkins**:将下载的war文件解压到你希望安装Jenkins的目录,通常我们会选择一个如 `/opt/jenkins` 的路径。 3. **创建plugins目录**:在Jenkins的安装目录下创建一个名为 `plugins` 的文件夹,这将是存放所有插件的地方。 4. **解压并移动插件**:将提供的 "plugins" 压缩包解压,然后将解压出的所有插件文件(它们是以 `.hpi` 或 `.jpi` 结尾的文件)移动到 `plugins` 目录下。这些插件包括了maven、Java、vue和git等,它们将为Jenkins提供对这些工具的支持。 5. **启动Jenkins**:启动Jenkins服务,这通常可以通过命令行执行Java命令完成,例如: ``` java -jar /path/to/jenkins.war --httpPort=8080 ``` 这里,`--httpPort=8080` 参数指定了Jenkins监听的端口,你可以根据实际需求进行调整。 6. **首次配置**:访问Jenkins的URL(如 `http://yourserver:8080`),按照提示进行初始化设置,包括设置管理员密码、安装推荐插件(此时因为我们已离线安装了所有插件,所以可以跳过此步)和创建第一个管理员用户。 7. **验证插件安装**:一旦Jenkins启动并完成了初始化,你可以登录并检查已安装的插件。进入管理页面,点击“管理Jenkins”->“系统信息”,在“已安装的插件”列表中,你应该能看到maven、Java、vue、git等插件都已成功安装。 通过以上步骤,你已经在无网络或内网环境中成功搭建了带有必要插件的Jenkins服务器。现在,你可以配置各种构建作业,如Maven项目、Java项目、Vue.js前端项目以及使用Git进行版本控制的项目。这将使你的CI/CD流程更加顺畅,无论是在代码构建、测试还是部署阶段。
2024-12-25 19:41:30 223.07MB jenkins
1
SNMP(Simple Network Management Protocol)是一种广泛用于网络设备管理的标准协议,它允许管理员远程监控和配置网络设备。在本离线下载包中,主要是为CentOS 8系统提供了SNMP服务的安装文件,确保在没有互联网连接的情况下也能进行安装。 在CentOS 8上安装SNMP服务对于网络管理至关重要,因为这将使你能够通过SNMP协议收集系统性能数据,监控网络设备状态,并在必要时进行远程配置。这个包特别强调了离线安装的适用性,意味着它包含了所有必要的依赖项,确保在没有网络连接的环境中也能顺利安装。 在提供的压缩包文件列表中,我们看到了一系列Perl相关和SNMP相关的RPM包,这些是安装SNMP服务所必需的组件: 1. `perl-interpreter-5.26.3-420.el8.x86_64.rpm`:这是Perl解释器的RPM包,Perl是编写SNMP管理工具和脚本的常用语言。 2. `perl-libs-5.26.3-420.el8.x86_64.rpm`:Perl运行库,是Perl解释器运行时所需的库文件。 3. `perl-Encode-2.97-3.el8.x86_64.rpm`:Perl的Encode模块,用于处理字符编码问题,确保数据在不同系统间正确传输。 4. `net-snmp-libs-5.8-22.el8.x86_64.rpm`:SNMP网络库,包含了SNMP协议操作所需的底层实现。 5. `net-snmp-agent-libs-5.8-22.el8.x86_64.rpm`:SNMP代理库,用于在网络设备上运行SNMP服务并响应管理站的查询。 6. `perl-Net-SSLeay-1.88-1.module_el8.3.0+410+ff426aa3.x86_64.rpm`:Perl的Net::SSLeay模块,提供了SSL/TLS协议支持,这对于安全的SNMP通信(如SNMPv3)至关重要。 7. `net-snmp-5.8-22.el8.x86_64.rpm`:SNMP主程序包,包含SNMP服务的控制台工具和守护进程。 8. `perl-IO-Socket-SSL-2.066-4.module_el8.3.0+410+ff426aa3.noarch.rpm`:Perl的IO::Socket::SSL模块,支持创建安全的套接字连接,与Net::SSLeay配合使用。 9. `net-snmp-utils-5.8-22.el8.x86_64.rpm`:SNMP实用工具,包括`snmpwalk`, `snmpget`, `snmpset`等,方便进行SNMP管理任务。 10. `perl-Pod-Simple-3.35-395.el8.noarch.rpm`:Perl的Pod::Simple模块,用于处理Perl文档格式(Plain Old Documentation)。 这些组件共同构成了一个完整的SNMP服务安装包,确保在CentOS 8系统上能正常工作。根据描述,该包已经在本地测试环境中成功安装,并且在客户环境中部署了超过100台机器,反馈良好,这表明了其稳定性和可靠性。 要安装这些文件,可以使用RPM命令行工具,例如: ```bash sudo rpm -ivh perl-interpreter-*.rpm perl-libs-*.rpm perl-Encode-*.rpm net-snmp-libs-*.rpm net-snmp-agent-libs-*.rpm perl-Net-SSLeay-*.rpm net-snmp-*.rpm perl-IO-Socket-SSL-*.rpm net-snmp-utils-*.rpm perl-Pod-Simple-*.rpm ``` 安装完成后,你可以使用`systemctl start snmpd`启动SNMP服务,并使用`systemctl enable snmpd`将其设置为开机启动。 这个离线SNMP下载包为CentOS 8系统提供了一种便捷的方式来安装和管理SNMP服务,即使在没有互联网连接的情况下也能有效进行网络设备的监控和管理。
2024-08-19 14:23:07 13.58MB snmp Centos linux
1
在IT行业中,持续集成与持续部署(CI/CD)是软件开发流程中的重要环节,而Jenkins作为一款广泛应用的开源自动化服务器,可以帮助我们实现这一目标。本文将详细讲解如何在无网络或内网环境中,利用提供的压缩包文件,搭建一个包含maven、Java、Vue.js和Git插件的Jenkins 2.328版本。 让我们理解Jenkins的基本概念。Jenkins是一个用Java编写的开源持续集成工具,它允许开发者通过自动化构建、测试和部署来加速软件开发过程。Jenkins支持各种语言和平台,并且拥有丰富的插件生态系统,能够适应各种项目需求。 对于无网络或内网环境,直接在线安装Jenkins插件是不可行的。因此,我们需要离线方式来安装所需的插件。在本例中,你已经有一个名为"plugins"的压缩包,其中包含了maven、Java、Vue.js和Git等相关插件。 1. **离线安装Jenkins插件步骤**: - 确保你已经在服务器上安装了Jenkins的基础版本。可以通过官方文档获取安装指南。 - 下载与你的Jenkins版本相匹配的插件压缩包,本例中为"plugins"。 - 解压缩这个文件到Jenkins的安装目录下的`plugins`文件夹。通常,这个路径会是`/var/lib/jenkins/plugins`或`C:\Program Files\Jenkins\plugins`,具体取决于你的操作系统。 - 一旦插件被复制到正确的位置,你需要重启Jenkins服务。在Linux系统中,可以使用`systemctl restart jenkins`或`service jenkins restart`命令,而在Windows中,可以在服务管理器中停止并重新启动Jenkins服务。 2. **配置Jenkins**: - 重启Jenkins后,访问它的URL(通常是http://localhost:8080或http://your_server_ip:8080),按照屏幕提示完成初始化设置,如设置管理员密码。 - 登录Jenkins,进入管理界面,选择“管理Jenkins”>“管理插件”>“已安装”,在这里你应该能看到刚刚离线安装的插件已列出来。 - 如果需要进一步配置这些插件,例如设置Maven、Git等的路径,可以分别在相应的插件设置中进行。 3. **使用插件**: - Maven插件:用于自动化构建和测试Java项目,确保Maven配置正确,并在Jenkins中创建Maven项目的配置。 - Java插件:虽然Jenkins本身是用Java写的,但这个标签可能是指Java项目的构建支持。确保Java环境已安装,并在Jenkins中配置好。 - Vue.js插件:可能指的是Vue.js应用的构建和测试支持。如果项目中包含Vue.js应用,需要配置相关构建脚本,如Webpack或Vue CLI。 - Git插件:用于从Git仓库中拉取代码,确保Git已安装,并在Jenkins中配置好Git凭证和仓库地址。 4. **注意事项**: - 确保所有依赖项(如Java、Maven、Git等)在服务器上已正确安装和配置。 - 当离线安装插件时,需要确保压缩包中的插件版本与Jenkins兼容,否则可能会出现运行错误。 - 在无网络环境中,记得定期更新和维护你的插件,以确保安全性和功能的完整性。 通过以上步骤,你就能在无网或内网服务器上成功搭建一个具备基本CI/CD功能的Jenkins环境,有效地支持maven、Java、Vue.js和Git相关的项目开发。这不仅提高了工作效率,也降低了出错的可能性。
2024-08-09 13:31:25 226.85MB jenkins
1
https://bbs.21ic.com/icview-1620370-1-1.html 根据此楼主的代码 移植到STM32F4,应用到MAX2 CPLD上,代码对内存要求减少很多,50多KRAM就足够了。
2024-07-16 11:38:57 2.42MB cpld stm32 离线下载器
1
内网jenkins(2.346.1)部署离线下载插件
2024-04-08 01:39:23 314.4MB jenkins
1
rfc是网络协义的重要学习资源,为方便大家查看,特收藏整理如下。下面是其中一篇内容: Network Working Group Steve Crocker Request for Comments: 1 UCLA 7 April 1969 Title: Host Software Author: Steve Crocker Installation: UCLA Date: 7 April 1969 Network Working Group Request for Comment: 1 CONTENTS INTRODUCTION I. A Summary of the IMP Software Messages Links IMP Transmission and Error Checking Open Questions on the IMP Software II. Some Requirements Upon the Host-to-Host Software Simple Use Deep Use Error Checking III. The Host Software Establishment of a Connection High Volume Transmission A Summary of Primitives Error Checking Closer Interaction Open Questions Crocker [Page 1] RFC 1 Host Software 7 April 1969 IV. Initial Experiments Experiment One Experiment Two Introduction The software for the ARPA Network exists partly in the IMPs and partly in the respective HOSTs. BB&N has specified the software of the IMPs and it is the responsibility of the HOST groups to agree on HOST software. During the summer of 1968, representatives from the initial four sites met several times to discuss the HOST software and initial experiments on the network. There emerged from these meetings a working group of three, Steve Carr from Utah, Jeff Rulifson from SRI, and Steve Crocker of UCLA, who met during the fall and winter. The most recent meeting was in the last week of March in Utah. Also present was Bill Duvall of SRI who has recently started working with Jeff Rulifson. Somewhat independently, Gerard DeLoche of UCLA has been working on the HOST-IMP interface. I present here some of the tentative agreements reached and some of the open questions encountered. Very little of what is here is firm and reactions are expected. I. A Summary of the IMP Software Messages Information is transmitted from HOST to HOST in bundles called messages. A message is any stream of not more than 8080 bits, together with its header. The header is 16 bits and contains the following information: Destination 5 bits Link 8 bits Trace 1 bit Spare 2 bits The destination is the numerical code for the HOST to which the message should be sent. The trace bit signals the IMPs to record status information about the message and send the information back to the NMC (Network Measurement Center, i.e., UCLA). The spare bits are unused. Crocker [Page 2] RFC 1 Host Software 7 April 1969 Links The link field is a special device used by the IMPs to limit certain kinds of congestion. They function as follows. Between every pair of HOSTs there are 32 logical full-duplex connections over which messages may be passed in either direction. The IMPs place the restriction on these links that no HOST can send two successive messages over the same link before the IMP at the destination has sent back a special message called an RFNM (Request for Next Message). This arrangement limits the congestion one HOST can cause another if the sending HOST is attempting to send too much over one link. We note, however, that since the IMP at the destination does not have enough capacity to handle all 32 links simultaneously, the links serve their purpose only if the overload is coming from one or two links. It is necessary for the HOSTs to cooperate in this respect. The links have the following primitive characteristics. They are always functioning and there are always 32 of them. By "always functioning," we mean that the IMPs are always prepared to transmit another message over them. No notion of beginning or ending a conversation is contained in the IMP software. It is thus not possible to query an IMP about the state of a link (although it might be possible to query an IMP about the recent history of a link -- quite a different matter!). The other primitive characteristic of the links is that there are always 32 of them, whether they are in use or not. This means that each IMP must maintain 18 tables, each with 32 entries, regardless of the actual traffic. The objections to the link structure notwithstanding, the links are easily programmed within the IMPs and are probably a better alternative to more complex arrangements just because of their simplicity. IMP Transmission and Error Checking After receiving a message from a HOST, an IMP partitions the message into one or more packets. Packets are not more than 1010 bits long and are the unit of data transmission from IMP to IMP. A 24 bit cyclic checksum is computed by the transmission hardware and is appended to an outgoing packet. The checksum is recomputed by the receiving hardware and is checked against the transmitted checksum. Packets are reassembled into messages at the destination IMP. Open Questions on the IMP Software Crocker [Page 3] RFC 1 Host Software 7 April 1969 1. An 8 bit field is provided for link specification, but only 32 links are provided, why? 2. The HOST is supposed to be able to send messages to its IMP. How does it do this? 3. Can a HOST, as opposed to its IMP, control RFNMs? 4. Will the IMPs perform code conversion? How is it to be controlled? II. Some Requirements Upon the Host-to-Host Software Simple Use As with any new facility, there will be a period of very light usage until the community of users experiments with the network and begins to depend upon it. One of our goals must be to stimulate the immediate and easy use by a wide class of users. With this goal, it seems natural to provide the ability to use any remote HOST as if it had been dialed up from a TTY (teletype) terminal. Additionally, we would like some ability to transmit a file in a somewhat different manner perhaps than simulating a teletype. Deep Use One of the inherent problems in the network is the fact that all responses from a remote HOST will require on the order of a half-second or so, no matter how simple. For teletype use, we could shift to a half-duplex local-echo arrangement, but this would destroy some of the usefulness of the network. The 940 Systems, for example, have a very specialized echo. When we consider using graphics stations or other sophisticated terminals under the control of a remote HOST, the problem becomes more severe. We must look for some method which allows us to use our most sophisticated equipment as much as possible as if we were connected directly to the remote computer. Error Checking The point is made by Jeff Rulifson at SRI that error checking at major software interfaces is always a good thing. He points to some experience at SRI where it has saved much dispute and wasted effort. On these grounds, we would like to see some HOST to HOST checking. Besides checking the software interface, it would also check the HOST-IMP transmission hardware. (BB&N claims the HOST-IMP hardware will be as reliable as the internal registers of the HOST. We believe Crocker [Page 4] RFC 1 Host Software 7 April 1969 them, but we still want the error checking.) III. The Host Software Establishment of a Connection The simplest connection we can imagine is where the local HOST acts as if it is a TTY and has dialed up the remote HOST. After some consideration of the problems of initiating and terminating such a connection , it has been decided to reserve link 0 for communication between HOST operating systems. The remaining 31 links are thus to be used as dial-up lines. Each HOST operating system must provide to its user level programs a primitive to establish a connection with a remote HOST and a primitive to break the connection. When these primitives are invoked, the operating system must select a free link and send a message over link 0 to the remote HOST requesting a connection on the selected link. The operating system in the remote HOST must agree and send back an accepting message over link 0. In the event both HOSTs select the same link to initiate a connection and both send request messages at essentially the same time, a simple priority scheme will be invoked in which the HOST of lower priority gives way and selects another free link. One usable priority scheme is simply the ranking of HOSTS by their identification numbers. Note that both HOSTs are aware that simultaneous requests have been made, but they take complementary actions: The higher priority HOST disregards the request while the lower priority HOST sends both an acceptance and another request. The connection so established is a TTY-like connection in the pre-log-in state. This means the remote HOST operating system will initially treat the link as if a TTY had just called up. The remote HOST will generate the same echos, expect the same log-in sequence and look for the same interrupt characters. High Volume Transmission Teletypes acting as terminals have two special drawbacks when we consider the transmission of a large file. The first is that some characters are special interrupt characters. The second is that special buffering techniques are often employed, and these are appropriate only for low-speed character at time transmission. We therefore define another class of connection to be used for the transmission of files or other large volumes of data. To initiate this class of link, user level programs at both ends of an established TTY-like link must request the establishment of a file-like connection parallel to the TTY-like link. Again the priority scheme comes into Crocker [Page 5] RFC 1 Host Software 7 April 1969 play, for the higher priority HOST sends a message over link 0 while the lower priority HOST waits for it. The user level programs are, of course, not concerned with this. Selection of the free link is done by the higher priority HOST. File-like links are distinguished by the fact that no searching for interrupt characters takes place and buffering techniques appropriate for the higher data rates takes place. A Summary of Primitives Each HOST operating systems must provide at least the following primitives to its users. This list knows not to be necessary but not sufficient. a) Initiate TTY-like connection with HOST x. b) Terminate connection. c) Send/Receive character(s) over TTY-like connection. d) Initiate file-like connection parallel to TTY-like connection. e) Terminate file-like connection. f) Send/Receive over file-like connection. Error Checking We propose that each message carry a message number, bit count, and a checksum in its body, that is transparent to the IMP. For a checksum we suggest a 16-bit end-around-carry sum computed on 1152 bits and then circularly shifted right one bit. The right circular shift every 1152 bits is designed to catch errors in message reassembly by the IMPs. Closer Interaction The above described primitives suggest how a user can make simple use of a remote facility. They shed no light on how much more intricate use of the network is to be carried out. Specifically, we are concerned with the fact that as some sites a great deal of work has gone into making the computer highly responsive to a sophisticated console. Culler's consoles at UCSB and Englebart's at SRI are at least two examples. It is clear that delays of a half-second or so for trivial echo-like responses degrade the interaction to the point of making the sophistication of the console irrelevant. We believe that most console interaction can be divided into two Crocker [Page 6] RFC 1 Host Software 7 April 1969 parts, an essentially local, immediate and trivial part and a remote, more lengthy and significant part. As a simple example, consider a user at a console consisting of a keyboard and refreshing display screen. The program the user is talking typing into accumulates a string of characters until a carriage return is encountered and then it processes the string. While characters are being typed, it displays the characters on the screen. When a rubout character is typed, it deletes the previous non-rubout character. If the user types H E L L O <- <- P where <- is rubout and is carriage-return, he has made nine keystrokes. If each of these keystrokes causes a message to be sent which in return invokes instructions to our display station we will quickly become bored. A better solution would be to have the front-end of the remote program -- that is the part scanning for <- and -- be resident in our computer. In that case, only one five character message would be sent, i.e., H E L P , and the screen would be managed locally. We propose to implement this solution by creating a language for console control. This language, current named DEL, would be used by subsystem designers to specify what components are needed in a terminal and how the terminal is to respond to inputs from its keyboard, Lincoln Wand, etc. Then, as a part of the initial protocol, the remote HOST would send to the local HOST, the source language text of the program which controls the console. This program would have been by the subsystem designer in DEL, but will be compiled locally. The specifications of DEL are under discussion. The following diagrams show the sequence of actions. Crocker [Page 7] RFC 1 Host Software 7 April 1969 A. Before Link Establishment / \ | +-----------+ +-----------+ | | | | | | | | | | | | | | | terminal | | terminal | | | | | | | | | | | | | | | +-----+-----+ +-----+-----+ | | | | | | | | | | | | | | +-----+-----+ +-----------+ | | | | | Request connection | | | | UCLA { | | | -> over link 25 | | | } SRI | | +-+-+ | +-+ +-+ | +-+-+ | | | | | OS|---+-=|I|----------|I|=-+---| OS| | | | | +-+-+ | +-+ +-+ | +---+ | | | | | | | | | | | | | | | +-----------+ +-----------+ | | HOST: UCLA HOST: SRI | \ / Crocker [Page 8] RFC 1 Host Software 7 April 1969 b. After Link Establishment and Log-in / \ | +-----------+ +-----------+ | | | | | | | | | | | | | | | terminal | | terminal | | | | | | | | | | | | | | | +-----+-----+ +-----+-----+ | | | | | | | | | | | | | | +-----+-----+ "Please send front"+-----------+ | | | | | end control" | | | | UCLA { | | | -> | | | } SRI ___ | | +-+-+ | +-+ +-+ | +--+---+ | | / | | | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| | | | +-+-+ | +-+ +-+ | +------+ | | |___/ | | | DEL prog. | | | | | | | | <- | | | |____| | +-----------+ +-----------+ | | HOST: UCLA HOST:SRI | \ / Crocker [Page 9] RFC 1 Host Software 7 April 1969 c. After Receipt and Compilation of the DEL program / \ | +-----------+ +-----------+ | | | | | | | | | | | | | | | terminal | | terminal | | | | | | | | | | | | | | | +-----+-----+ +-----+-----+ | | |Trivial | | | |Responses | | | | | | | +-----+------+ +-----------+ | | | | | | | | | UCLA { | | | Major Responses | | | } SRI ___ | | +--+--+ | +-+ +-+ | +--+---+ | | / | | | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| | | | |front| | +-+ +-+ | +------+ | | |___/ | | | end | | | | | | | | | |prog.| | | | | |____| | | +-----+ | | | | | | | OS | | | | | | | +-----+ | | | | | | | | | | | +------------+ +-----------+ | | HOST: UCLA HOST: SRI | \ / Open Questions 1. If the IMPs do code conversion, the checksum will not be correct. 2. The procedure for requesting the DEL front end is not yet specified. IV. Initial Experiments Experiment One SRI is currently modifying their on-line retrieval system which will be the major software component on the Network Documentation Center so that it can be operated with model 35 teletypes. The control of the teletypes will be written in DEL. All sites will write DEL compilers and use NLS through the DEL program. Experiment Two Crocker [Page 10] RFC 1 Host Software 7 April 1969 SRI will write a DEL front end for full NLS, graphics included. UCLA and UTAH will use NLS with graphics. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Celeste Anderson 3/97 ] Crocker [Page 11]
2024-01-01 10:17:35 111.74MB
1
官方链接:https://www.ni.com/zh-cn/support/downloads/drivers/download.ni-visa.html#460225 支持Labview2019 2018 2017 2016,参考自https://www.ni.com/zh-cn/support/documentation/compatibility/16/ni-visa-and-labview-version-compatibility.html
2023-10-15 19:50:04 926.31MB labview 驱动 ni-visa
1
OruxMaps使用、地图合成、离线下载2013.11教程
2023-04-04 10:39:54 15.71MB OruxMaps 地图合成
1
DIY STM32离线下载器(仅SWD模式)
2023-03-02 14:56:27 18.52MB stm32 DIY 离线下载器
1
IE11 Win7 64 离线下载包 IE11 Win7 64 离线下载包分两部分,全部免费
2022-12-08 20:52:13 40MB IE11 Win7 64 离线下载包
1