配置項包括但不限於哪些

Ⅰ 什麼是配置

什麼是軟體配置項？一般認為：軟體生存周期各個階段活動的產物經審批後即可稱之為軟體配置項。
軟體配置項包括：

–①與合同、過程、計劃和產品有關的文檔和資料；

–②
源代碼、目標代碼和可執行代碼；

–③相關產品，包括軟體工具、庫內的可重用軟體、外購軟體及顧客提供的軟體等。

在軟體建立時變更是不可避免，而變更更回劇了項目中軟體工程師間的混亂。之所以產生混亂，是因為在進行變更前沒有仔細分析，或沒進行變更控制。Babich曾經這樣說過：「協調軟體開發使得混亂達到最小的技術叫配置管理。配置管理是一種標識、組織和控制修改的技術，目的是使錯誤達到最小並最有效地提高生長率。

軟體配置管理，叫SCM，它應用於整個軟體工程過程。因為變更在任何時刻都可能發生，因此SCM活動的目標就是為了(1)標識變更；(2)控制變更；(3)確保變更正確地實現(4)向其他有關的人員報告變更。

軟體配置管理是貫穿整個軟體生存周期的一項技術。它的主要功能是控制軟體生存周期中軟體的改變，減少各種改變所造成的影響，確保軟體產品的質量。正確應用軟體配置管理是開發高質量軟體所不可缺少的。軟體配置管理的過程是軟體開發過程中質量管理的精髓。

所謂硬體配置文件，是指在啟動計算機時告訴Windows應該啟動哪些設備，以及使用每個設備中的哪些設置的一系列指令。

Ⅱ 電腦配置包括哪些內容

主板 內存 硬碟 CPU 顯卡 電源 鍵盤滑鼠 顯示器 音響

Ⅲ 常見的軟體配置項有哪些

csci是計算機軟體配置項(computer
software
configuration
item)簡稱，在軟體設計文檔中經常用到。
配置與配置項
在配置管理中，「配置」和「配置項」是重要的概念，「配置」是在技術文檔中明確說明並最終組成軟體產品的功能或物理屬性。因此「配置」包括了即將受控的所
有產品特性，其內容及相關文檔，軟體版本，變更文檔，軟體運行的支持數據，以及其他一切保證軟體一致性的組成要素，相對與硬體類配置，軟體產品的「配置」
包括更多的內容並具有易變性。
受控軟體經常被劃分為各類配置項（configuraion
items,
cis），這類劃分是進行軟體配置管理的基礎和前提，cis是邏輯上組成軟體系統的各組成部分。比如一個軟體產品包括幾個程序模塊，每個
程序模塊及其相關文檔和支撐數據可能被命名為一個ci。一個系統包括的cis的數目是一個與設計密切相關的問題，關於怎樣將一個軟體系統劃分為不同的
cis將在以下有關章節中闡述，注意如果一個產品同時包括硬體和軟體部分，一般一個ci也同時包括軟體和硬體部分，一個純軟體的ci通常也稱之為軟體配置
項（csci）。本規范的ci一般指csci，軟硬體的配置管理有一些相通的地方，但因為軟體更易於修改，所以軟體配置管理是一個更應該系統化的過程。
基線與基線管理
各cis隨軟體開發活動的進展，會有越來越多的部件進入受控狀態。一般地，軟體開發過程從概念演繹和需求分析開始，然後是設計，各cscis的編碼或寫
作，集成測試，最後是用戶手冊的編寫等。軟體配置管理包括了在軟體生命周期的時間分散點上對各cis進行標識並對對他們的修改進行控制的過程。在一個開發
階段結束或一組功能開發完成後，要對相應的cis進行基線化並形成各類基線。在配置管理系統中，基線就是一個ci或一組cis在其生命周期的不同時間點上
通過正式評審而進入正式受控的一種狀態，而這個過程被稱為「基線化」。每一個基線都是其下一步開發的出發點和參考點。
每個基線都將接受配置管理的嚴格控制，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟體開發階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線，這就是「基線管理」的過程，因此基線具有以下屬性：
通過正式的評審過程建立
基線存在於基線庫中，對基線的變更接受更高許可權的控制
基線是進一步開發和修改的基準和出發點。
一般地，第一個基線包含了通過評審的軟體需求，因此稱之為「需求基線」，通過建立這樣一個基線，受控的系統需求成為進一步軟體開發的出發點，對需求的變更被正式初始化、評估。受控的需求還是對軟體進行功能評審的基礎。

Ⅳ 好多合同條款里的「包括但不限於」是什麼意思

合同條款裡面為了嚴謹可能都會寫到包括，但不限於這樣的詞彙，這個到底是什麼意思？其實它是一種范圍的擴大。因為它後面加了一個等它列舉了一些事項，但並不代表僅包括這些事項，差了一個等，差了包括但不限於，那最終表達的意思就不一樣了。

這個詞彙可不能隨便使用的，因為它是一種范圍的擴大，對於違約責任被違約方的權益保護起到了非常好的作用，但是如果你不注意的話，它也有可能成為侵犯你合法權益的一個東西，因為它擴大你的工作職責並不算違法，但你不注意的話。因為這個和公司發生扯皮，到時候你再去走勞動仲裁或者是提起訴訟，維護自己的合法權益，這就會很困難。

Ⅳ 軟體測試中什麼是配置項測試具體定義和具體工作是什麼

配置項測試的理解，我覺得得先清楚兩個概念：

①軟體配置項：我認為軟體配置項就是一個開發完成的,已經進入配置管理的,准備提供給客戶的產品。可以是可執行代碼，也可以是產品文檔。

②軟體需求規格說明書：軟體需求規格說明書是在項目前期進行需求分析的時候得到的一份文檔，這份文檔中描述了用戶的需求，是初始階段甲乙雙方對項目的共同理解，比如一些界面設計，流程描述，這個是整個開發工作的基礎。

那麼配置項測試，就可以理解成是對軟體配置項的一種檢查，檢查它與軟體需求規格說明書是否一致。比如對可執行代碼進行功能測試，關注它的功能是否與軟體需求規格說明書中要求的一致。或者對一份產品文檔進行文檔審查，關注是否已經按照軟體需求規格說明書中要求，描述了安裝步驟，或者文檔中描述的介面是否與軟體需求規格說明書中的相同。

所以配置項測試，需要在單元測試和集成測試之後進行。

我理解的測試順序應該是：單元測試->集成測試->配置項測試->系統測試->確認測試，如果項目存在變更，還需要進行回歸測試。當然，這個只是幫助理解，實際中肯定不會是按順序做的。

Ⅵ 關於項目管理中配置管理的實現過程，配置項的知識請教以及相比版本管理的差異

你的理解更多是「產品集成」的概念，即怎麼把幾個產品模塊或構件組合成一個產品，但這不是配置管理的概念。
配置管理：簡稱CM（Configuration Management的縮寫），標識、控制和管理變更的一種管理活動。它控制配置項的修改和發行；記錄和報告配置項的狀態和變更；保證配置項的完整性、一致性和正確性；以及控制配置項的儲存、裝載和交付。
根據這個定義，配置管理的主要工作包括：
1）配置庫的管理活動。配置庫現在工具非常多，例如GIT、SVN、CVS、VSS等等。通常會根據開發所處的階段，設立開發庫、受控庫與產品庫。
2）標識配置項，即需要定義如何去標識配置項。配置管理中受控制的對象被稱為配置項，是生命周期中創建的信息，包含程序、數據、文檔，分基線配置項和非基線配置項兩類。特別是你的產品最終是如何標識的，比如怎樣定義V1.0.0的規則。
3）基線的管理。是一組經過正式審查並且達成一致的規范或工作產品，是下一階段工作的基礎。怎樣確定、發布基線，怎樣管理基本的變更。
4）配置項變更管理。可以根據不同的配置項、不同的開發周期，明確變更的管理規則。
5）配置項狀態管理與配置審計 。

而產品集成是如何把一個產品逐步的從一個個模塊或組件，最後組合成一個產品的過程。
1）首先產品的技術結構上要能夠支持，如果模塊不能相互獨立和拆解，談不上靈活的組合。
2）在開發實現上，需要有一個集成的策略，哪些先實現，哪些後實現，哪些可以先進行集成
3）需要建立 集成的環境，使開發好的模塊可以在集成環境中進行調試
4）通常開發完成後，需要進行源代碼的編譯，並打包成一個測試包，然後裝在集成環境中，進行調試，以確認各個模塊之前是否可以兼容和運轉，這時通常會進行測試工作。
5）如果你想進行ABC組合，或者AC組合，那麼都需要進行相應的編譯、打包（例如形成EXE）過程，然後在集成環境中進行聯調和測試。

Ⅶ 什麼是配置項管理

按管理的嚴格程度，配置項一般分3個等級：
（1）納入基線管理的配置項
納入基線管理的配置項是指變化時要走嚴格變更手續的配置項，需要做變更申請，要審批。審批一般分2種嚴格程度：
i) 項目經理或分CCB審批就可以，一般是局部的小的變更。
ii）變更控制委員會（CCB）審批
納入基線前，一般要經過評審或測試（稱為驗證）和質量保證。
(2) 沒有納入基線但是也不能隨意變更的配置項，一般稱為受控項
這類配置項不需要變更申請，但是要經過配置管理員或項目經理的允許才可以變更。
基線項與受控項寫的許可權要唯一，一般是CM或PM有唯一的寫許可權。
（3）非受控項
對變更不做控制。

擬納入基線管理的配置項狀態變化一般是先非受控，然後受控，最後基線化。變更時，先檢出（checkou）進行修改，修改完畢後再檢入（checki）轉為受控，等待驗證（測試或評審），通過驗證後進行基線化。

擬納入受控而不入基線的配置項狀態變化一般是先非受控，然後受控。變更時，檢出進行修改，修改完畢後再檢入提交受控。

納入基線管理的時機是管理平衡問題，一般是當配置項基本穩定後才納入基線管理，如果處與頻繁的變動之中，納入基線後會增加管理成本，如單元測試通過後一般不形成基線，因為此時代碼並不穩定，但是可以作為受控項，也不能任意變化。這個問題的判斷也和項目組的規模有關系，如果規模很大，涉及到的人員很多，也可能需要建立基線。在系統測試後要形成基線，一般稱為產品基線，此時系統基本穩定了，可以對外發布，為更多的人所了解和使用了。代碼在沒有納入基線但是受控後（提交測試人員測試了），也不能隨便變更了，要經過配置管理員的批准，並通知測試人員。

Ⅷ 軟體配置項包括哪些內容

軟體配置項包括：①與合同、過程、計劃和產品有關的文檔和資料；②源代碼、目標代碼和可執行代碼；③相關產品，包括軟體工具、庫內的可重用軟體、外購軟體及顧客提供的軟體等

Ⅸ 計算機軟體配置項是什麼

1、軟體配置項（SCI）：軟體生存周期各個階段活動的產物經審批後即可稱之為軟體配置項。

2、軟體配置項包括：

（1）與合同、過程、計劃和產品有關的文檔和資料；

（2）源代碼、目標代碼和可執行代碼；

（3）相關產品，包括軟體工具、庫內的可重用軟體、外購軟體及顧客提供的軟體等。

3、軟體配置項是作為配置項識別活動的產出物，CMMI中要求有文檔化的配置項識別准則，根據准則來進行配置項識別，列出配置項列表，給與配置項唯一的編號、名稱等，並標明配置項的一些重要屬性，如：它的存儲位置、它的負責人、對應源碼語言、受控級別等。

(9)配置項包括但不限於哪些擴展閱讀：

1、軟體配置相關

Babich曾經這樣說過：「協調軟體開發使得混亂達到最小的技術叫配置管理。配置管理是一種標識、組織和控制修改的技術，目的是使錯誤達到最小並最有效地提高生長率。

軟體配置管理，叫SCM，它應用於整個軟體工程過程。因為變更在任何時刻都可能發生，因此SCM活動的目標就是為了：

(1)標識變更；

(2)控制變更；

(3)確保變更正確地實現;

(4)向其他有關的人員報告變更。

Ⅹ 如何從 Oracle Solaris 10 實時安裝到 Oracle Solaris 11 11/11

為新安裝的 Oracle Solaris 11 11/11 系統（存檔系統）中的根池及其關聯數據集創建 ZFS 存檔。創建存檔時，可以將其保存在本地可移動介質中，如 USB 驅動器，也可以通過網路將其發送到一個文件伺服器以便稍後從中檢索。需要使用存檔時，執行以下高級步驟：
在將要遷移到 Oracle Solaris 11 11/11 的 Oracle Solaris 10 系統（遷移系統）上啟動一個具有超級用戶許可權的 shell。
選擇並配置一個引導磁碟設備，創建新的 ZFS 根池。
在新池中恢復存檔的 ZFS 數據集。
執行最終配置，然後重新啟動遷移系統。
遷移系統必須是運行 Oracle Solaris 10 的主機，並且其 ZFS 版本與存檔系統兼容。對於將要遷移到新磁碟或系統的 ZFS 存檔，確保滿足以下要求：
存檔系統和遷移系統為同一型號（如 SPARC T 系列）並且滿足 Oracle Solaris 11 11/11 的最低要求。
遷移系統運行 Oracle Solaris 10 8/11 或更高版本，這是必須的，這樣才能具有與 Oracle Solaris 11 11/11 兼容的 ZFS 版本。
如果遷移系統運行的是 Oracle Solaris 10 8/11，請在嘗試恢復存檔之前應用以下 ZFS 補丁。沒有這個補丁，任何恢復存檔的嘗試都將失敗。對於 Oracle Solaris 10 以後的任何版本，無需此補丁。
註：應用補丁之後，必須重新啟動遷移系統。
補丁 147440-11 或更高版本，用於基於 SPARC 的系統
補丁 147441-11 或更高版本，用於基於 x86 的系統
確保將要存放新 ZFS 池的磁碟的總容量至少與存檔池中分配的空間一樣大。准備一節將更詳細地討論這一方面。
您必須同時擁有存檔系統和遷移系統上的根許可權。存檔將包含所存檔 ZFS 數據集中包含的所有軟體和配置信息。注意，不支持通過系統存檔遷移區域。遷移完成之後，您可以使用另外的過程（不在本文討論范圍之內）將 Oracle Solaris 10 區域遷移到 solaris10 標記區域。還要注意，在 Oracle Solaris 11 系統上無法運行 Oracle Solaris 8 或 Oracle Solaris 9 區域。有關如何將 Oracle Solaris 10 區域遷移到solaris10 標記區域的詳細信息，請參見 Oracle Solaris 管理：Oracle Solaris 區域、Oracle Solaris 10 區域和資源管理。
所創建的存檔不會具有期望的系統配置，因為我們將在一台主機上創建存檔，最終將在另一台主機上運行該存檔，這是兩台不同的主機。第 4 階段介紹（遷移之後）存檔的配置。有必要在遷移完成後、引導 Oracle Solaris 11 11/11 之前，重新配置存檔中的每個引導環境。為此，存檔應只包含一個引導環境 (BE)。有關系統配置的詳細信息，請參見安裝 Oracle Solaris 11 系統 第 6 章「取消配置或重新配置 Oracle Solaris 實例」。
存檔映像中不包含任何硬體特定的配置數據。不隨備份一起轉移的硬體特定的系統特性包括但不限於以下內容：
磁碟容量和配置（包括 ZFS 池配置）
硬體乙太網地址
已安裝的硬體外圍設備
第 1 階段：創建 Oracle Solaris 11 11/11 存檔
圖 1 說明創建 Oracle Solaris 11 11/11 存檔時所發生的情況。

圖 1. 創建 Oracle Solaris 11 11/11 存檔
准備
為准備遷移，記下遷移系統上根池的磁碟拓撲結構和 ZFS 池配置。和存檔系統上的磁碟一樣地對遷移系統上的目標磁碟進行配置，並相應調整新 ZFS 池的大小。分配的池的大小（以下所示的 zpool list 輸出中的 ALLOC 列）至少需要確保有充足的空間來在遷移系統上恢復數據集。
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 68G 51.6G 16.4G 75% 1.00x ONLINE -

如果任何存檔池的容量（如 CAP 列所示）超過 80%，最佳實踐要求應擴大遷移池以規劃容量。根據其他配置元素和負載的不同，增加池中的空間餘量還可能有益於性能。有關如何管理 ZFS 文件系統及相關性能的更多信息，請參閱 Oracle Solaris 管理：ZFS 文件系統 指南。
為准備稍後的遷移，將各種命令的輸出保存到一個文件，與存檔一起保存以供遷移期間參考。清單 1 中所示命令只是最低建議，根據系統配置的不同，其他配置信息也可能有用。清單 1 中顯示的命令與示例輸出僅針對 rpool。
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 68G 51.6G 16.4G 75% 1.00 ONLINE -

# zpool get all rpool
NAME PROPERTY VALUE SOURCE
rpool size 68G -
rpool capacity 75% -
rpool altroot - default
rpool health ONLINE -
rpool guid 18397928369184079239 -
rpool version 33 default
rpool bootfs rpool/ROOT/snv_175a local
rpool delegation on default
rpool autoreplace off default
rpool cachefile - default
rpool failmode wait default
rpool listsnapshots off default
rpool autoexpand off default
rpool depditto 0 default
rpool depratio 1.00x -
rpool free 16.4G -
rpool allocated 51.6G -
rpool readonly off -

# zpool status
pool: rpool
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c5t0d0s0 ONLINE 0 0 0

errors: No known data errors

# format c5t0d0s0
selecting c5t0d0s0
[disk formatted]
/dev/dsk/c5t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).

FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show disk ID
volname - set 8-character volume name
!<cmd> - execute <cmd>, then return
quit
format> p
PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
!<cmd> - execute <cmd>, then return
quit
partition> p
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 root wm 1 - 14086 68.35GB (14086/0/0) 143339136
1 unassigned wm 0 0 (0/0/0) 0
2 backup wu 0 - 14086 68.35GB (14087/0/0) 143349312
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0

partition> ^D
#

清單 1. 各種命令的輸出
將清單 1 所示的來自存檔系統的信息以及遷移期間可能有用的任何其他信息置於一個文件中，並將該文件與存檔文件保存在同一位置以便稍後在遷移過程中使用。
也可以使用 Oracle Explorer Data Collector 收集所有系統配置信息以供稍後參考。有關 Oracle Explorer Data Collector 及其相關文檔的信息可在 Oracle Services Tools Bundle for Sun Systems 網站中找到。
有關 ZFS 管理和容量規劃的其他信息，請參閱 Oracle Solaris 管理：ZFS 文件系統 指南。
創建存檔
要存檔根池並包括所有快照，需要創建 ZFS 復制流。為此，首先從池的頂級創建遞歸快照，如下所述。同樣，可以對需要存檔並傳給遷移主機的其他池進行存檔。
注意，rpool 是默認的根池名稱，但在任何給定系統上根池可能有不同的名稱。可以使用 beadm list -d 確定 BE 駐留在哪個池。在本文的其餘部分，將使用默認名稱 rpool 引用根池。
使用以下命令創建根池的遞歸快照。快照名稱（本例中為 archive）可以基於日期或您需要的任何其他描述性標簽。
# zfs snapshot -r rpool@archive

接下來，刪除交換和轉儲設備快照，因為它們可能不包含任何相關數據，刪除它們通常會顯著降低存檔的大小。
註：關於轉儲設備，盡管可能性不大，但轉儲設備也有可能有數據尚未被提取到 /var 數據集（以核心存檔的形式）。如果是這種情況，且應保存轉儲設備的內容，則在刪除轉儲設備快照之前將內容轉儲輸出到文件系統。詳情參見 mpadm(1M)。
以下命令將刪除默認命名的交換和轉儲設備快照，雖然主機上可能部署了其他快照。要確定是否存在默認命名設備之外的其他設備，可使用swap(1M) 和 mpadm(1M) 分別列出交換和轉儲設備的名稱。
# zfs destroy rpool/swap@archive
# zfs destroy rpool/mp@archive

既然快照已經准備好，下一步是將其發送到文件進行存檔。如果要存檔多個 ZFS 池，每個池將有一個快照，每個快照需要發送到自己的存檔文件。以下步驟主要是創建根池的存檔。不過，可用同樣的方式對系統上的任何其他池進行存檔。
要將快照發送到文件，請通過管道將 zfs send 命令的結果輸出到 gzip 命令（如下所示），結果產生一個壓縮文件，其中包含池快照的存檔。創建此存檔文件時，一個好的主意是，使用反映主機名、日期或其他有助於稍後確定存檔內容的描述性詞語的唯一命名方法。
您可以將存檔文件保存在本地以便稍後進行重定位，也可以在可移動介質上創建存檔文件。存儲存檔文件的位置應是定期備份的文件系統。同時，盡管使用了壓縮，文件系統上仍應有足夠的可用存儲空間。一個好的經驗是有足夠的空間容納 zpool list 報告的 ALLOC 量的總和。
使用以下命令在本地創建存檔文件。存檔文件名可以是任何有助於識別此存檔以便稍後使用的字元串。通常的選擇可能是使用主機名加日期，如以下示例所示。
# zfs send -Rv rpool@archive | gzip > /path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz

現在，將存檔文件移到文件伺服器以便稍後檢索，如圖 2 所示。

圖 2. 確保可訪問 Oracle Solaris 11 11/11 存檔
還可以選擇將存檔文件直接寫入掛載 NFS 的路徑，如下所示：
# zfs send -Rv rpool@archive | gzip > /net/FILESERVER/path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz

類似地，可以通過 ssh 以流方式將存檔文件發送到文件伺服器：
# zfs send -Rv rpool@archive | gzip | ssh USER@FILESEVER "cat> /path/to/archive_$(hostname)_$(date +%Y%m%d).zfs.gz"

注意，如果通過網路以流方式傳送存檔，ssh 傳輸不支持任何一種斷點續傳功能。因此，如果網路連接中斷，將需要重新啟動整個命令。
遷移存檔文件已創建，現在可以使用以下命令刪除本地快照：
# zfs destroy -r rpool@archive

第 2 階段：准備配置 Oracle Solaris 11 11/11 系統
在引導遷移的 Oracle Solaris 11 11/11 實例之前，可通過從運行 Oracle Solaris 10 的遷移系統收集所有相關系統配置參數來准備遷移。需要收集的系統配置項包括但不限於以下內容：
主機名
時區
區域設置
根口令
管理員用戶信息
主網路介面（如果不是自動配置）
名稱服務信息
有關所需數據的信息，請參見安裝 Oracle Solaris 11 系統 第 6 章「取消配置或重新配置 Oracle Solaris 實例」。
在恢復存檔時須重新生成系統配置信息。可以這樣來完成這一任務：在運行中的 Oracle Solaris 11 11/11 系統上生成 SC (System Configuration) 配置文件，然後將該配置文件復制到恢復的 Oracle Solaris 11 11/11 存檔以便在第一次引導時自動應用。
sysconfig 的 create-profile 子命令調用 SCI Tool 介面，向您詢問系統配置信息，然後生成一個 SC 配置文件，您稍後可以用它來配置系統。
使用以下命令在本地創建 SC 配置文件。配置文件名可以是任何有助於識別該配置文件以便稍後使用的字元串。以下示例使用附有日期信息的 config。
# sysconfig create-profile -o /path/to/config_$(date +%Y%m%d).xml

然後將 SC 配置文件移到文件伺服器以便稍後檢索。
還可以選擇創建 SC 配置文件並將其直接寫入掛載 NFS 的路徑，如下所示。
# sysconfig create-profile -o /net/FILESERVER/path/to/config_$(date +%Y%m%d).xml