【教学培训篇】体验openUBMC

也许你已经在openUBMC社区学习与探索了许久,却一直缺少对openUBMC Web界面的直观感受,至今仍对它有些模糊;
也许你曾在某个时刻、某个地方浏览过openUBMC的Web界面,但冰冷的静态截图已无法满足你的好奇,你渴望能够亲手操作、真实体验一番;
又或者,你其实早已体验过openUBMC的Web界面,却苦于没有长期稳定的环境,一直梦想能拥有一台专属于自己的openUBMC服务器。

现在,我们很高兴地告诉你:拥有一台虚拟的openUBMC服务器不再是梦想!你可以随时随地亲手操作、深入体验openUBMC的各项功能——这一切,只需借助开源的QEMU虚拟化平台,我们已成功基于它搭建出的openUBMC产品。

前期准备

你只需要完成以下几个简单步骤,就能立即开启属于你的openUBMC体验之旅。。。

git clone git@gitcode.com:openUBMC/manifest.git

cd manifest

python3 init.py -path <bmc_sdk.zip文件路径> -user <openUBMC社区用户名> -psw <openUBMC社区用户密码>

python3 build/works/packet/qemu_shells/vemake_1711.py

解析说明:
1、将openUBMC的manifest仓clone到本地
2、进入manifest仓,初始化环境变量
3、运行qemu:python3 build/works/packet/qemu_shells/vemake_1711.py

qemu的运行和电脑性能是强相关,现在的你可能会疑惑:究竟什么时候基于qemu拉起的openUBMC是可以使用的呢?当出现终端出现下面回显信息的信息时,就可以体验openUBMC。

notify security core that bmc has successfully started

体验openUBMC

web

网站:https://ip:10443
账号:Administrator
密码:Admin@90000

注意ip:可以使用ifconfig查询,也可以使用127.0.0.1


ssh

方式一
在xshell里面创建连接,账号密码同web


方式二
直接在终端使用如下命令:

ssh Administrator@localhost -p 10022
密码:Admin@90000

redfish

在这里使用postman进行演示

ipmi

使用ipmitool工具

ipmitool -I lanplus -H xxx -U Administrator -P Admin@90000 -p 10623 -C 17 xxx

telnet

使用xshell工具,在这里你可以使用在线调试等功能…


还要搭运行环境呢,也不是manifest直接搞下来就能用

有些启动qemu的依赖项放在init.py里面,需要运行一次python3 init.py,要不然直接拉起qemu的时候会报缺少一些动态库

我们当前还是比较依赖运行os的,换个os,init.py就跑不了了

这的确是一个问题,到时候可以一起商量能不能做一下多操作系统的方式,扩大使用场景

如果能通过docker_compose的方式 用容器来分发镜像就更无感了.

Yocto 支持部分发行版做原生构建,但官方更倾向 LTS 系(如 Ubuntu/Debian系)。Arch、Gentoo、以及节奏更快的 Fedora 不在保障范围:依赖更新频繁、ABI/包名易变,维护和回归成本过高。
这类系统大部分开发者也是用Docker/LXC 固定构建环境,避免大体量依赖“污染”桌面,若要扩展原生支持,优先 LTS,滚动发行版不建议直接适配

主要是docker使用上没问题,但是用来作为开发环境还是有点不好用,这也是我先在很苦恼的事情,直接装环境又会遇到各种问题

init.py是不是要直接分配到工具里面比较好,该是bingo的依赖就放在bingo里面,该是qemu的依赖就放qemu,然后由工具去拓展各种开发环境

docker不好用体现在哪里呀;
我们现在是docker镜像导出为wsl镜像, 再导入wsl去使用, 牺牲了管理能力, 但是基本达到原生体验了

你这个思路听上去可以,理论上docker的container不是一个应该去长期使用的容器,他更多是一个一次性的或者按需创建启动的,当工作结束后就应该销毁
作为开发环境的话,他的数据不持久化,只能通过-v镜像的方式,主机和容器的权限经常会出问题。然后端口访问也受限,毕竟是一个受限容器
WSL确实给windows研发环境带来了挺多便利的,所以最早我们也是选这个作为环境方案

嗯,我们当前环境搭建走的是一键式部署,自然所有东西都会在一起
如果要优化的话,可以围绕init去进行拆分,但暂时感觉意义不太大,主要问题还是当前部分依赖安装的时候没优化,导致与具体构建环境耦合