Day: July 30, 2020
This newsletter includes:
- CHGOWN: Easily Change Object Ownership
- The Importance of Being On Time: How to Configure the NTP Client on IBM i
- iTech iTip Videos
- What does “secure connection error, return code-23” mean?
- No. Your IBM i Isn’t Secure.
- [ Webinar Series ] Sips & Tricks: Coffee with iTech
- [Podcast Episode] Disaster Recovery: What’s the Difference Between the Various Components?
- Upcoming Events
- IBM i, FSP, and HMC release levels and PTFs ( July 2020)
First, I hope you and your families are healthy, safe, and secure as the virus creates a new “normal” in our daily lives. I liked the old normal much better, but inside every black cloud is a silver lining. It’s up to all of us to search and reach out to find that. You know the saying from lemons we make lemonade. May you enjoy your lemonade as we all get used to changes in our lives.
I had my first flight in 5 months, the airport was empty, and the flight was certainly different. Different parts of the country are handling this differently, and the wearing of masks exemplified this. Here in Connecticut, almost 100% of the people are wearing masks, but this wasn’t the case in other states that I had visited.
IBM Releases New POWER9 Models
Well, July was a big month for IBM i and Power Systems, as IBM delivered a new small low-end POWER9 based machine, a refresh of the 914/924 models, finally straighten out the Technology Refresh confusion, and more NVMe options. Let’s start with these.…
With the push to secure all data traffic to our critical systems, many organizations are moving to secured versions of classic technology. One project we see repeatedly is the switch from insecure FTP to encrypted FTPS. Not to be confused with SFTP, FTPS stands for FTP over SSL/TLS and it is to FTP what HTTPS is to HTTP. Just like secure web pages, FTPS uses a system of certificates to encrypt and secure FTP transfers. If you’re making the switch to FTPS, you may find that you begin to receive the error message “Secure connection error, return code -23” when you attempt to connect to another system.
Return code 23 means the certificate in use on the remote server is not signed by a trusted authority. This is caused by one of two things:
- The server is using a self-signed certificate
- The server is using a commercial certificate issued by an entity for which IBM i does not have a built-in root certificate.
To correct this, the CA certificate used to sign the server’s certificate needs to be imported into DCM on the IBM i and marked as trusted. You will need to obtain a copy of that CA certificate in the form of a .cer file which needs to be placed in the IFS where DCM will be able to read it. The server administrator should be able to provide this file or tell you how to obtain it.
If the certificate being used was issued by a commercial entity, you may be able to download what you need directly from the issuer’s website (assuming you can figure out who that is). Once the CA is trusted by the system then all certificates signed by it—including the one in use on this FTP server—will automatically be trusted by extension. That should eliminate the error.…
I had an interesting but not surprising conversation with a customer last week to talk about IBM i security. They said:
“IBM i is just bulletproof. We don’t have to worry about security. That’s the value of IBM i.”
It’s something heard all too often. And that’s my cue to tell someone just how ugly their baby is. I’m not going to sugar coat it because the stakes are far too high.
Once again, IBM i is highly securable.
Perhaps more than any other operating system ever created. It is not secure out of the box. In fact, it’s actually shipped wide open. The system value QCRTAUT has a good hand in making it that way. If QCRTAUT is the default value of *CHANGE (and it usually always is), then any object created on the system has *PUBLIC *CHANGE authority. In layman’s terms, it means that all objects are wide open to any authenticated user. This is the shipped value. And it’s only one of many things you need to keep under control.…
When managing your IBM i environment, is time on your side?
Do you still manually maintain the system clock on your IBM i system and occasionally adjust it to exactly the right time and/or still manually correct it in the Spring/Fall when we roll the clocks forward/backward? Well, read on, and we’ll tell you how to configure the system to automatically do that for you so you can put your system’s clock management on full autopilot.
Your IBM i operating system includes built-in support for the industry-standard NTP (Network Time Protocol) client. This functionality enables you to configure your system as an NTP “client” where the system will continually reach out to public time servers and/or local time servers already on your network to automatically adjust your system clock and keep it always at the precise time. Your system can not only serve as an NTP client to keep its clock accurate but it can also serve as an SNTP (Simple Network Time Protocol) server to serve-up the correct time to client servers on your network, or it can serve as an SNTP client, but this article will focus on setting-up the NTP client functionality on IBM i as this is typically what most shops need to enable. Many people think that SNTP and NTP are the same and they are not, both protocols have the same objective, to automatically keep the time on your system correct by referencing an external time server, but NTP client functionality is more complex & precise in how it verifies the correct time and adjusts the system clock, thus it is the time adjustment protocol of choice in most server environments because it provides a higher degree of accuracy and reliability than an SNTP client configuration.…
Object ownership is very important on IBM i, as often group profiles are used to secure objects, and sometimes programs are compiled to run under the authority of the profile that owns the program. There are times when a decision is made to change the owner of a particular library in order to change the scheme of securing objects, or you may go to restore a library to another system, and realize that the profile that owned the objects on the original system, does not exist on the target system to take the ownership. Sometimes in these cases, the library has hundreds or even thousands of objects in them, and changing the owner of these objects one at a time is just not feasible. There are several ways to resolve this, but certainly, the easiest way is to use the CHGOWN command.…