The industry really can’t stop talking about the edge. In the interest of not starting a classic “edge” conversation with a definition, let’s focus very specifically about its role as a new business model for 5G. From a Telco perspective, 5G enables a whole range of new applications and services that will open the doors to new revenue streams and provide a path to differentiation. Aligning business outcomes to vertical industry requirements to operating models to technology enablers has become the foundation for how Dell Technologies is discussing the edge with our Telco customers and partners … READ MORE
Tag: Du
Smart Dubai Extends Its Blockchain-focused Products with New BPaaS
Emirates Integrated Telecommunications Company, commercially rebranded as du in 2007 has announced it received an endorsement for its Blockchain Platform as a Service (BPaaS) from the Smart Dubai, states the official statement.
Smart Dubai is the government office charged with facilitating Dubai’s citywide smart transformation, to empower, deliver and promote an efficient, seamless and safe city experience for residents and visitors.
Related:
How to Free Space From /var Directory of NetScaler Appliance When Unable to Log on to NetScaler GUI
Run the following commands to view the contents of the /var directory:
cd /varls -l
The directories that are usually of interest are as follows:
/var/nstrace – This directory contains trace files.This is the most common reason for HDD being filled on the NetScaler. This is due to an nstrace being left running for indefinite amount of time. All traces that are not of interest can and should be deleted. To stop an nstrace, go back to the CLI and issue stop nstrace command.
/var/log – This directory contains system specific log files.
/var/nslog – This directory contains NetScaler log files.
/var/tmp/support – This directory contains technical support files, also known as, support bundles. All files not of interest should be deleted.
/var/core – Core dumps are stored in this directory. There will be directories within this directory and they will be labeled with numbers starting with 1. These files can be quite large in size. Clear all files unless the core dumps are recent and investigation is required.
/var/crash – Crash files, such as process crashes are stored in this directory. Clear all files unless the crashes are recent and investigation is required.
/var/nsinstall – Firmware is placed in this directory when upgrading. Clear all files, except the firmware that is currently being used.
Related:
SyncIQ and Snapshot Restore
Got an interesting snapshot restore question from the field that thought would make a useful blog article:
“I need to restore a large amount of data. Unfortunately the snapshots are taken at the root level and I cannot restore every subdirectory under the snapshot. Although the files are not large the subdirectories contain anywhere from thousands to tens of millions of files. Restores are taking a very long time when copying the directories manually. Is there a faster way to do this?”
There are two main issues here:
- Since the snapshot is taken at a lower level in the directory tree and the entire snapshot cannot be restored in place, the SnapRevert job is not an option here.
- The sheer quantity of files involved mean that a manual, serial restore of the data will be incredibly time consuming.
Fortunately, there is a solution using replication. SyncIQ allows for snapshot subdirectories to be included or excluded, plus also provides the performance benefit of parallel job processing.
SyncIQ contains an option only available via the command line (CLI) which allows replicate out of a snapshot.
The procedure is as follows:
1) Create a snapshot of a root directory:
# isi snapshot snapshots create –name snaptest3 /ifs/data
2) List the available snapshots and select the desired instance.
For example:
# isi snapshot list
ID Name Path
—————————————————-
6 FSAnalyze-Snapshot-Current-1529557209 /ifs
8 snaptest3 /ifs/data
—————————————————-
Total: 2
Or from the WebUI:
Note: There are a couple of caveats:
- The subdirectory to be restored must still exist in the HEAD filesystem (ie. not have been deleted since the snapshot was taken).
- You cannot replicate data from a SyncIQ generated snapshot.
3) Create a local SyncIQ replication policy with the snapshot source as the original location and a new directory location on ‘localhost’ as the destination. The ‘—source-include-directories’ argument lists the desired subdirectory(s) to restore.
For example, via the CLI:
# isi sync policies create snapshot_sync3 sync /ifs/data localhost /ifs/file_sync3 –source-include-directories /ifs/data/local_qa
Or via the WebUI:
Note: You cannot configure the snapshot into the policy, or set source=snapshot.
4) Next, run the sync job to replicate a subset of a snapshot. This step is CLI only (not WebUI) since the SyncIQ policy needs to be executed with ‘–source-snapshot’ argument specified.
For example:
# isi sync job start snapshot_sync3 –source-snapshot=snaptest3
Note: This command is essentially a change root for the single run of the SyncIQ Job.
5) Finally, rename the original directory to something else with mv, and then rename the restore location to the original name.
For example:
# mv /ifs/data/local_qa /ifs/data/local_qa_old
# mv /ifs/file_sync3/local_qa /ifs/data/local_qa
Note: If you do not have a current replication license on your cluster, you can enable the OneFS SyncIQ trial license from the WebUI by browsing to Cluster Management > Licensing. Failing that, contact your local account team and they can provide you a demo license.
Using SyncIQ in this manner is a very efficient way to recover large amounts of data from within snapshots. However, this scenario also illustrates one of the drawbacks of taking snapshots at the root directory level. Consider whether it’s more advantageous to configure snapshot schedules to capture at the subdirectory directory level instead.
Related:
7.3.0 patch 2 mlocate issue
Since I have upgraded, I have been getting disk usage messages from /var being at 94%. After some research I found that /var/lib/mlocate/mlocate.db is being updated and the temp file is taking up 20% of the partition. When I run updatedb -v, I see that it is indexing everything in /store/ariel/. Is that expected behavior? I feel it is why the mlocate process is taking so much space.
Related:
InsightIQ directory chart maximum depth settings
I was helping an Isilon SE understand how InsightIQ utilizes the results from the File System Analyze job. It occurred to me that there may be some confusion between the “directory filter maximum depth” and the “directory chart maximum depth” settings in InsightIQ. Specifically, SEs and customers are wondering how they are able to drill deep into the directory structure using the directory browser widget when their FSA maximum depth is set to only 5 deep.
These two settings are located in the InsightIQ application, under SETTINGS -> configure (for the selected cluster) -> FSA Configuration tab:
Directory chart maximum depth
Under FILE SYSTEM REPORTING -> File System Analytics, both the Data Usage and Data Properties reports offer the “directory chart” graph module. This module is also commonly referred to as the “directory browser module” or “directory browser widget”. It looks like this:
Many users find this widget particularly useful as you could drill into various directories, see and sort by sub-directory count, file count, logical size, and physical sizes. The maximum depth at which you could drill into the /ifs directory structure is limited by the directory chart maximum depth setting. The default setting is -1, which means unlimited.
In the screenshot above, I am able to drill down to 12levels deep from the /ifs root; while the directory filter maximum depth is only set to 5. Here lies the potential confusion.
Directory filter (path_squash) maximum depth
The directory filter maximum depth setting limits the depth of the directories that are included in the filtering options, which also affects the directory filter breakouts. The default depth is 5. The deeper this setting, the bigger the size of the FSA result set on-cluster.
Please see the blog in the related resources section for some common uses of the directory filter.
Related Resources
Related:
Event ID 9010 — IIS Application Host History Configuration
Event ID 9010 — IIS Application Host History Configuration
Updated: January 20, 2010
Applies To: Windows Server 2008
The ApplicationHost Helper Service (AppHostSvc) maintains a history of Internet Information Services (IIS) configuration by saving the ApplicationHost.config file to separate configuration history subdirectories. If you make a mistake when you modify the ApplicationHost.config file, you can restore an earlier version of the file from a configuration history subdirectory by copying the earlier version into the %Windir%\system32\inetsrv\config directory. You can specify the frequency with which AppHostSvc checks for configuration changes, the path of the directory that contains the subdirectories, and how many subdirectories to keep.
By default, the Application Host Helper Service checks for changes in the ApplicationHost.config file every two minutes. If it detects that the configuration has changed, it creates a backup. The default location for the configuration history files is %SystemDrive%\inetpub\history. AppHostSvc creates one subdirectory under this directory for each configuration file backup. By default, the maximum number of history subdirectories is 10. If the number of configuration history subdirectories reaches the maximum specified, the oldest subdirectory is deleted.
AppHostSvc is a runtime-independent service that does not require the Windows Process Activation Service (WAS) or the World Wide Web Publishing Service (W3SVC) to operate. AppHostSvc does not depend on any other service and its startup type is Automatic. If the ApplicationHost Helper Service is stopped, the configuration history feature will not work.
Event Details
| Product: | Internet Information Services |
| ID: | 9010 |
| Source: | Microsoft-Windows-IIS-APPHOSTSVC |
| Version: | 7.0 |
| Symbolic Name: | APPHOSTSVC_HISTORY_CANT_ACCESS_HISTORY_DIR_ERROR |
| Message: | The Application Host Helper Service encountered an error trying to access the root history directory ‘%1’. The directory either doesn’t exist or the permissions on it don’t allow the history service to access it. The config history feature is disabled for now and will be re-enabled after the issue is resolved. To resolve this issue, please ensure that the directory exists and that the Administrators group have read and write access to it. The data field contains the error number. |
Resolve
Check the configuration history directory path and permissions
To main IIS configuration history, the Application Host Helper Service requires that the history directory that you specified exists and that the Administrators Group has read and write permissions for it. The default configuration history directory is %SystemDrive%\inetpub\history.
To perform these procedures, you must have membership in Administrators, or you must have been delegated the appropriate authority.
To ensure that the history directory that is specified exists and has the correct permissions, follow these steps:
A. Back up the ApplicationHost.config file
- Open an elevated Command Prompt window. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
- At the command prompt, type cd %Windir%\system32\inetsrv.
- Type appcmd add backup backupName to backup the ApplicationHost.config file.
A directory with the backup name you specify will be created under the %windir%\system32\inetsrv\backup directory. If you do not specify a name, appcmd will generate a directory name automatically using the current date and time.
B. Find the current history directory setting
- At an elevated Command Prompt window, type cd %Windir%\system32\inetsrv\config.
- Type notepad ApplicationHost.config.
- In notepad, search for the configHistory section under the system.applicationHost section.
- Find the path attribute and read its value. The default is %SystemDrive%\inetpub\history.
- Make sure that the path is correctly spelled and has no errors.
- Save and close the ApplicationHost.config file.
C. Ensure that permissions for the history directory are correct
- Click Start, click Computer, and navigate to the directory that you found in the path attribute of the configHistory section in the ApplicationHost.config file.
- Right-click the history directory and click Properties.
- Click the Security tab.
- Under Group or user names, click the System account. Under Permissions, make sure that the System account has full control.
- If the System account does not have full control, click Edit and select the Systems account again. Under Permissions, select the Allow check box to the right of Full Control.
- Perform the previous two steps for the Administrators account.
- Click OK to exit Properties.
See Also
IIS 7.0: configHistory Element (IIS Settings Schema)
Verify
To verify the configuration of the AppHostSvc configuration history backup feature, you can do the following:
- Use notepad to examine the current configHistory section settings in the ApplicationHost.config file.
- Use the Appcmd.exe command-line administration utility to view the configHistory section in the ApplicationHost.config file.
To perform these procedures, you must have membership in Administrators, or you must have been delegated the appropriate authority.
View the configHistory section by using notepad
To view the configHistory section by using notepad:
- Open an elevated Command Prompt window. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
- Type cd %Windir%\system32\inetsrv\config.
- Type notepad ApplicationHost.config.
- In notepad, search for the configHistory section under system.applicationHost. The contents should resemble the following:
<system.applicationHost>
<configHistory enabled=”true” path=”%SystemDrive%\inetpub\history” maxHistories=”10″ period=”00:02:00″ />
</system.applicationHost>
View the configHistory section by using Appcmd.exe
To view the configHistory section by using Appcmd.exe:
- Open an elevated Command Prompt window. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
- Type cd %Windir%\system32\inetsrv.
- Type appcmd list config “Default Web Site” /section:configHistory /config:*. (This example uses the default Web site; replace the site name as necessary.)
See Also
IIS 7.0: configHistory Element (IIS Settings Schema)
Related Management Information
IIS Application Host History Configuration
Internet Information Services (IIS) 7.0
Related:
Re: Re: WebUI login issues for Admin user
In addition to D_Tracy’s suggestions, we can try to rule out the case
that already removed files which are kept in open status by some process
still consume disk space.
du -sxh /var
summarizes the disk space taken by all visible files in /var (excluding /var/crash).
If this value is much lower than the number reported by df,
then you have such ‘dark matter’, and if the related process(es)
cannot be identified, the node would need to be rebooted.
— Peter
Related:
gazuk created a blog entry named duvg – show space usage in AIX filesystems, but sorted by Volume Group in the Tricks of the Power Masters (Regular updates, please visit often) blog.
gazuk060000MAFC created a blog entry named duvg – show space usage in AIX filesystems, but sorted by Volume Group in the Tricks of the Power Masters (Regular updates, please visit often) blog.
Related:
The Windows Directory Service database has %1 MB of free space out of %2 MB of allocated space.
| Details | |
| Product: | Windows Operating System |
| Event ID: | 1646 |
| Source: | Active Directory |
| Version: | 5.0 |
| Symbolic Name: | DIRLOG_DB_FREE_SPACE |
| Message: | The Windows Directory Service database has %1 MB of free space out of %2 MB of allocated space. |
| Explanation | |
|
This is an Active Directory internal event. Internal events appear in Event Viewer only when the default logging level is changed. Most internal events are for informational purposes only. This event is logged when the Active Directory database has the specified amount of free hard disk space remaining. |
|
| User Action | |
|
No user action is required. |
|