Currently ood-control and cyfs-stack util both support returning some information abou

Customizing system info about cyfs HOT 3 OPEN

lurenpluto commented on June 16, 2024

Customizing system info

from cyfs.

Comments (3)

lurenpluto commented on June 16, 2024

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

from cyfs.

lurenpluto commented on June 16, 2024

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

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
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

from cyfs.

lurenpluto commented on June 16, 2024

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

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

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); 
        
           }

from cyfs.

Customizing system info about cyfs HOT 3 OPEN

Comments (3)

Current situation of system info related logic

1. stack.util.get_system_info logic

2. ood-control's system info logic

3. ood-control's check logic

Solutions to consider

1. SYSTEM_INFO_MANAGER support for adding custom information

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

3. `SYSTEM_INFO_MANAGER` return system info need to add some fields

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

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

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	#[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,
	}

	// 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(),
	));

	#[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>,
	}

	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);
	}

Comments (3)

Current situation of system info related logic

1. stack.util.get_system_info logic

2. ood-control's system info logic

3. ood-control's check logic

Solutions to consider

1. SYSTEM_INFO_MANAGER support for adding custom information

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

3. SYSTEM_INFO_MANAGER return system info need to add some fields

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

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

Related Issues (20)

Recommend Projects

Recommend Topics

Recommend Org

3. `SYSTEM_INFO_MANAGER` return system info need to add some fields

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