Customizing system info

[lurenpluto]

Currently ood-control and cyfs-stack util both support returning some information about the current system, including hardware information and other key information, but this information is not well supported by some system environments, and some environments, such as running in docker, may lead to incorrect information, so consider providing users with the ability to customize some information such as Hardware information can be provided as a patch for "system information" under certain circumstances.

[lurenpluto]

Current situation of system info related logic

Currently, due to various historical reasons, the following system information is involved in the entire cyfs-services

1. stack.util.get_system_info logic

Support the same zone query system info, using the global single instance SYSTEM_INFO_MANAGER to get the system information

CYFS/src/component/cyfs-util/src/util/system_info.rs

Lines 6 to 37 in 3cd354a

	#[derive(Clone, Debug, Serialize, Deserialize)]
	pub struct SystemInfo {
	pub name: String,
	// How long the system has been running since it was last booted, in microseconds
	pub uptime: u64,
	// The time the system was last booted, in bucky time
	pub boot_time: u64,
	pub cpu_usage: f32,
	// memory size in bytes
	pub total_memory: u64,
	pub used_memory: u64,
	// Bytes transferred between each refresh cycle
	pub received_bytes: u64,
	pub transmitted_bytes: u64,
	// total bytes of all networks since last booted
	pub total_received_bytes: u64,
	pub total_transmitted_bytes: u64,
	// SSD drive capacity and available capacity, including Unknown, in bytes
	pub ssd_disk_total: u64,
	pub ssd_disk_avail: u64,
	// HDD capacity and available capacity, in bytes
	pub hdd_disk_total: u64,
	pub hdd_disk_avail: u64,
	}

2. ood-control's system info logic

This logic is consistent with the above, both use the global singleton SYSTEM_INFO_MANAGER

CYFS/src/service/ood-control/src/http_server.rs

Lines 178 to 189 in 3cd354a

	// system_info
	server.at("/system_info").get(HandlerEndpoint::new(
	RequestType::SystemInfo,
	access_token.clone(),
	handler.to_owned(),
	));
	server.at("/system_info/").get(HandlerEndpoint::new(
	RequestType::SystemInfo,
	access_token.clone(),
	handler.to_owned(),
	));

3. ood-control's check logic

It is used to check whether the current stack has bound the identity(device.desc & device.sec), and return some information about the current system, but the difference is that a new structure is used to express the information

CYFS/src/service/ood-control/src/request.rs

Lines 6 to 18 in 3cd354a

	#[derive(Serialize, Deserialize, Debug, Clone)]
	pub struct DeviceInfo {
	pub mac_address: String,
	pub model: String,
	pub device_sn: String,
	pub processor_brand: String,
	pub total_memory: u64,
	pub ssd_total_disk_space: u64,
	pub ssd_available_disk_space: u64,
	pub hdd_total_disk_space: u64,
	pub hdd_available_disk_space: u64,
	pub private_ip_address: Vec<String>,
	}

It partially uses the fields in the system info, but does not use the SYSTEM_INFO_MANAGER global singleton, and there are some fields and the above two points in the system info is not the same

Solutions to consider

So from the above logic can be seen, if we need to support external custom information, then it is better to improve the implementation of the global singleton SYSTEM_INFO_MANAGER, users can report part of the custom information, so consider the following changes may be involved

1. SYSTEM_INFO_MANAGER support for adding custom information

When used externally, the existing fields in the custom information will take precedence over the fields generated by the internal logic

2. improve the device_info returned by the check logic of ood-control

device_info involves system info related fields, which also need to follow SYSTEM_INFO_MANAGER

3. SYSTEM_INFO_MANAGER return system info need to add some fields

Add the fields in device_info that are available now but not in system_info

4. Support external update, the following two interfaces need to add the corresponding update logic

a. stack.util.set_system_info

b. set_system_info of ood-control component

5. Permission issues

Who has permission to update this information? Theoretically, only the administrator can

a. stack.util.set_system_info requires the system dec identity of the same zone's device

b. ood-control needs to be cyfs://static or internal to the browser's plugin to be called

[lurenpluto]

The user-defined system information part of the fields, we can consider two approaches

1. Through static configuration method
   For example, in {cyfs}/etc/system_info, configure custom fields, this scale can be used for fixed information, because the configuration file is generally pre-installed, no subsequent changes; the disadvantage is that it can only be used to configure fixed fields in system info, such as hardware information, etc., while some dynamic fields are difficult to configure with this mode

2. Through the interface
   The advantage of this mode is the greater freedom, and for some real-time refresh information inside the system info, it can also be updated in a timely manner; the disadvantage is that additional RPC calls are required to update the program or web page. Operation

At present, according to the product feedback on the use of scenarios, the second mode can be supported first, and then consider adding the first mode as needed

[lurenpluto]

The user-defined system information part of the fields, we can consider two approaches

1. Through static configuration method
   For example, in {cyfs}/etc/system_info, configure custom fields, this scale can be used for fixed information, because the configuration file is generally pre-installed, no subsequent changes; the disadvantage is that it can only be used to configure fixed fields in system info, such as hardware information, etc., while some dynamic fields are difficult to configure with this mode
2. Through the interface
   The advantage of this mode is the greater freedom, and for some real-time refresh information inside the system info, it can also be updated in a timely manner; the disadvantage is that additional RPC calls are required to update the program or web page. Operation

At present, according to the product feedback on the use of scenarios, the second mode can be supported first, and then consider adding the first mode as needed

Already based on mode 2, add update_system_info related implementation
The sample code used is as follows

CYFS/src/tests/cyfs-stack-test/src/case/util.rs

Lines 204 to 222 in 9eaf33f

	async fn update_system_info() {
	let user1_ood = TestLoader::get_shared_stack(DeviceIndex::User1OOD);
	// let user1_device1 = TestLoader::get_shared_stack(DeviceIndex::User1Device1);
	let mut req = UtilUpdateSystemInfoRequest::default();
	req.common.dec_id = Some(cyfs_core::get_system_dec_app().clone());
	req.info.name = Some("test update".to_owned());
	req.info.total_memory = Some(1024 * 1024);
	req.info.used_memory = Some(1024);
	req.info.device_sn = Some("123456".to_owned());
	info!("will update system info");
	user1_ood.util().update_system_info(req).await.unwrap();
	info!("update system info complete");
	let req = UtilGetSystemInfoRequest::new();
	let system_info = user1_ood.util().get_system_info(req).await.unwrap();
	info!("{}", system_info);
	}