Set the background color for midnight commander in pre 8 redhat clones

With the version 8 of redhat and clones, alike oracle or centos, you have the new layout option in the configuration to set a theme for your midnight commander appearance. In lower versions however, you need to start mc with selected options or modify ~/.config/mc/ini in that respect. If you’re just fine with the overall color usage but kind of dislike the the bright blue background color of mc on your otherwise more dark themed terminals / desktop, here is the command line or init file directive to apply for file listing (mc) and edit mode (mcedit) views.

command line

init file

And that’s how it might look like with gray3. For other colors in a short overview use mc --help-color , for a more in depth documentation man mc. https://midnight-commander.org/wiki/doc/common/skins may also be helpful.

Have fun

OTRS Dashboard / Widget Customization and Extension Howto

If you happen to find the widgets available for the otrs dashboard, supplied by the default installation, out of line with your in house workflow or just off your needs and taste, here is how to move things further.

Peeking the web for a way to introduce own, self-configured widgets, the top notch hit is (really): https://forums.otterhub.org/viewtopic.php?t=28631 , yet another of interest surely: http://lists.otrs.org/pipermail/otrs/2017-January/042897.html . crythias shows how to start off in general and shares some precious information about the url-parameters available for filtering (not officially shared on https://doc.otrs.com).

However, for the complete picture, first of all, administration of (initially supplied) otrs widgets can be managed in the admin console. do head, as usual, to: https://myhost/otrs/index.pl?Action=AdminSysConfig and just search for “widget” (so, at least, i got there, other ways may work alike).

Within the result set showing up, find the link to “Frontend::Agent::Dashboard” of group-type “Ticket” (there may be other groups concerning the dashboard):

Upon click, forms of all the active dashboard widgets along a plenty of configuration parameters will appear, the state “new tickets” widget may look as follows:

There are two interesting things to mention here:

1. The widget identifier, e.g. "DashboardBackend###0120-TicketNew" is what you need to redefine for your own widget definition in /opt/otrs/Kernel/Config/Files/Ticket.xml , or much better / professional in your own new in-house xml-file, Ticket-Local.xml or whatever.
   

2. The widget module name has another counterpart in the file system, such that "Kernel::Output::HTML::Dashboard::TicketGeneric" equals /opt/otrs/Kernel/Output/HTML/Dashboard/TicketGeneric.pm . If you do not only want to reinstate an existing widget template with an adjusted configuration but also want / need to hack the widget code itself (a perl module format) for another layout, for example, go there.
   

Ok, then, some additional Ticket-Local.xml file may turn out to read as follow. Note the new widget identifier in line #3 as well as the adapted where clause url-parameters (attributes) in line #26. Ordering is by column Age, ascending, by default, such that there is no explicit statement required here.

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="1.0" init="Application">
  <ConfigItem Name="DashboardBackend###0301-PtxSysTicket01" Required="0" Valid="1">
    <Description Translatable="1">Parameters for the dashboard backend of
        the open tickets overview of the agent interface.
      _Limit_ is the number of entries shown by default.
      _Group_ is used to restrict the access to the plugin (e. g.
        Group:admin;group1;group2;).
      _Default_ determines if the plugin is enabled by default or if the
        user needs to enable it manually.
      _CacheTTLLocal_ is the cache time in minutes for the plugin.
      Note: Only Ticket attributes and Dynamic Fields (DynamicField_NameX)
        are allowed for DefaultColumns. Possible settings: 0 = Disabled,
        1 = Available, 2 = Enabled by default.
    </Description>
    <Group>Ticket</Group>
    <SubGroup>Frontend::Agent::Dashboard</SubGroup>
    <Setting>
      <Hash>
        <Item Key="Module">Kernel::Output::HTML::Dashboard::TicketGeneric</Item>
        <Item Key="Title" Translatable="1">Live Tickets, ex pending Icinga</Item>
        <Item Key="Description" Translatable="1">
          All new, open, pending etc. tickets, excluding the items from
            Icinga that wait in a pending reminder after a recovery.
        </Item>
        <Item Key="Attributes">StateType=new;StateType=open;</Item>
        <Item Key="Filter" Translatable="1">All</Item>
        <Item Key="Time">Age</Item>
        <Item Key="Limit">10</Item>
        <Item Key="Permission">rw</Item>
        <Item Key="Block">ContentLarge</Item>
        <Item Key="Group"></Item>
        <Item Key="Default">1</Item>
        <Item Key="CacheTTLLocal">0.5</Item>
        <Item Key="DefaultColumns">
          <Hash>
            <Item Key="Age">2</Item>
            <Item Key="Changed">1</Item>
            <Item Key="Created">1</Item>
            <Item Key="CustomerCompanyName">1</Item>
            <Item Key="CustomerID">1</Item>
            <Item Key="CustomerName">1</Item>
            <Item Key="CustomerUserID">1</Item>
            <Item Key="EscalationResponseTime">1</Item>
            <Item Key="EscalationSolutionTime">1</Item>
            <Item Key="EscalationTime">1</Item>
            <Item Key="EscalationUpdateTime">1</Item>
            <Item Key="TicketNumber">2</Item>
            <Item Key="Lock">1</Item>
            <Item Key="Owner">1</Item>
            <Item Key="PendingTime">1</Item>
            <Item Key="Queue">1</Item>
            <Item Key="Responsible">1</Item>
            <Item Key="Priority">1</Item>
            <Item Key="Service">1</Item>
            <Item Key="State">1</Item>
            <Item Key="SLA">1</Item>
            <Item Key="Title">2</Item>
            <Item Key="Type">1</Item>
          </Hash>
        </Item>
      </Hash>
    </Setting>
  </ConfigItem>
</otrs_config>

Since otrs does not feature a syntax to express multiple value facets for an attribute, the clause term for a dedicated attribute may have to be repeated as necessary. Do note also, that then domain of actually possible attributes is somewhat undocumented (guide me if you know better). One may browse other widget configurations in /opt/otrs/Kernel/Config/Files/Ticket.xml but there is not much to inspect. We also have this set of attributes shared by crythias on otterhub, like this:

Types TypeIDs CreatedTypes CreatedTypeIDs States StateIDs CreatedStates CreatedStateIDs StateTypeIDs Locks LockIDs OwnerIDs ResponsibleIDs CreatedUserIDs Queues QueueIDs CreatedQueues CreatedQueueIDs Priorities PriorityIDs CreatedPriorities CreatedPriorityIDs Services ServiceIDs SLAs SLAIDs WatchUserIDs

And from the naming scheme we see, may conclude, for example, that there is a StateType, a StateTypes (multi) and a StateTypeIDs (multi-id) attribute. Nevertheless, you may need to test this on the spot, e.g. StateTypes did not work for me, any identifiers from StateTypeIDs originate from the database, look it up there.

Have fun, Peter

Undo retention, flashback query and ora-01555 snapshot too old

Setting up a fault aware database environment is in charge of regarding possible physical and logical error scenarios. On the physical side of the medal, you got real-application-cluster or dataguard at your disposal. The logical one usually comprises backup and replication. Recently, oracle and others introduced features that enables a database to recover from logical errors without or with less remote systems and data. Namely flashback is a powerful technology to look back into (query), back out (transaction) or fully restore (database) the history of data. Flashback of course takes accompanying (history) (meta)data to do its job, namely again, undo-before-images, archived-redo-logs and flashback-logs. So, essentially, the convenience of your course into history depends on the amount of history metadata that is available to the database at the time of a logical error, say an inadvertant delete from.

You may already have learned or heard about or even hardly experienced that flashback-logs may be purged from the recovery-area in favour of archived-redo-logs, rendering your configured flashback-retention-time (DB_FLASHBACK_RETENTION_TARGET) a value of theory. So far, sizing the file-system recovery-area is a task to be performed in a clear-sighted manner. The same is true then for undo-before-images (compare to logs) und the undo-tablespace (compare to area) to accomodate enough data to meet your configured undo-retention-time (UNDO_RETENTION) in UNDO_MANAGEMENT=AUTO mode, while in addition still support long running workload queries (not to overwrite old undo). This article discusses the usability of the (enterprise-manager) undo-advisor in sizing your undo-tablespace to always foster successful flashback queries up to the configured undo-retention-time (as opposed to the nasty surprise of getting an ora-01555, see below, which is also misleading here, imho, in suggesting that the undo-tablespace is to small now, as we know it from workload queries – nope, it has been to small before now, in the past, as regarded to flashback queries – also see : ora-01555 snapshot too old when running flashback query).

Understanding “occurrences before alerts” in oracle enterprise manager 13c

The Incident Manager within Oracle Enterprise Manager 13c is a powerful tool for monitoring a wealth of target types such as databases, hosts, middleware or just services in general from a bird’s eye view or right down into the manifold details of a dedicated application. As with all powerful means around, where there is a lot of power, there also usually is a lot to do wrong (or even employ counterproductive). This is why it is important to understand the Incident Manager concepts from bottom up and be able to identify the knobs and wheels to poke with to meet a certain requirement.

Basically, Incident Manager is a professional toolset to facilitate the management of non-critical and critical system alerts against metric values (registered as problems and incidents, see About Incidents and Problems) in a larger quantity and time scale along with alert management templating and alert assigment and so forth.

Splitting a btrfs 4.1x root partition with debian live system gparted btrfs tools 3.17-x

This is a short picture log of doing a btrfs 4.1x root partition split on a (down) oracle linux 7.2 using a debian live system applying gparted based on btrfs tools 3.17-x. Lot’s of names and version codecs, right? But this is what matters. The important message is : it works using this flavours.
Actually, running oracle or redhat linux as the live system may have been much more appropriate concerning compatibility reasons. The odd things is, no redhat-based (enterprise) linux system features gparted. Only fedora does, sourcing the epel-repository but not having kinf of a live system release as debian.