De tudo mais um pouco

I have a situation where: Frames attached on HMC using the dhcp range 192.128 But due network requirements it was necessary change the range. To avoid any problem, I opened a ticket with IBM Support and they give me the following solution: Is not need power off hte lpars on the frame. Is not need power off the frames. Not need to ask a onsite support to remove frames from power and power on again. Just access the network configuration on HMC and change the DHCP range on the interface. After that reboot the HMC. With that the DHCP lease on frame side will expire and get the new IP address. Can last 20 minutes to the frame get the new IP after the HMC rebooted. On the HMC interface you will see the frame lost connection but will be back soon, give it time. If the solution above do not work you or a onsite support will need unplug the cable on the frame side FSP port. Leave unplugged for 3  minutes and plug back. Only unplug on the frame side, not the HMC. Fortunatelly it was not nece...

I faced a situation where I needed test if I was able to reach a NIM server ports for the NIM service, problem is that is not so easy test all the ports, the hard way for example if you need test if would be possible resotre a machine is start the mksysb restore on the NIM and on the client, boot the server on the SMS services and see if will start normally hte installation. As per the documentation below: https://www.ibm.com/support/pages/nim-communication-within-firewall-environment You can see that thare are several port/services used by the NIM, is not feasible discover only in a critical moment that you have ports blocked on the firewall. Is not possible start all the services to test from the NIM clients. So the easy way is. You identify a service that respond for telnet on the localhost. Telnet to this service, on my case I saw the port 513 up: bash-5.0# telnet localhost 513 Trying... Connected to loopback. Escape character is '^]'. Testing from the NIM clients I was abl...

When try to use yum on AIX you may face the following error: As you can see is something related to hash. After checking the system with the command rpm -qa I noticed that a very old version of openssl, from 2002, was installed, so I just removed it, no impact for the system as all is to use the native ssl version installed on AIX: [root@server1]/mnt/> rpm -e openssl-0.9.6b-3.ppc openssl-doc-0.9.6b-3.ppc warning: /var/ssl/openssl.cnf saved as /var/ssl/openssl.cnf.rpmsave [root@server1]/mnt/> Remember to recreate the file /var/ssl/openssl.cnf.rpmsave to avoid any issues cp -p /var/ssl/openssl.cnf.rpmsave /var/ssl/openssl.cnf

When try to use yum on AIX you may face the following error: To fix, just create the needed file with touch command: root@server::/var/lib/rpm> ls -ltra /var/lib/rpm/Packages ls: 0653-341 The file /var/lib/rpm/Packages does not exist. root@server::/var/lib/rpm> touch /var/lib/rpm/Packages     

On AIX if you run the command updtvpkg to update the rpm database you can have a error like: Please wait...error: line 10: Dependency tokens must begin with alpha-numeric, '_' or '/': Provides: .nfs0BF6 I dont have much time to digg more deeper on this problem but from what I found is happens because the updtvpkg try to calculate the library dependency and happens to find the file above .nfs0BF6 in a folder scanned by the command. If you check the command, it is a script, you will see the following part: Packager: auto-generated" # Check for local shared libraries /usr/bin/lslpp -Ou -qfc | /usr/bin/cut -d':' -f3 | /usr/bin/cut -d' ' -f1 |\   /usr/opt/rpm/lib/rpm/find-provides | while read shobj do    echo "Provides: $shobj" done This specific part: /usr/bin/lslpp -Ou -qfc You can run it on the terminal is responsible for the first part of the scan, is where that bad fille was showing. To temporally fix the issue I just edited the command, ...

viosecure command can be a problem if you apply the high level of hardening on a system. If you wish you can apply only a set of values on your environment. First thing that you need to do is get the file /etc/security/aixpert/core/viosecureall.xml Check the xml file and you can see that on the file you will have all the set of harderning rules for high, medium and low. If you decide to apply the high, be in mind that certain things can stop working. So to easy things you can starting apply only some set of rules that you consider important. Below is the content of a customized file that you can start using to apply the minim history size for example: <?xml version="1.0" encoding="UTF-8"?> <!--     @(#)45    1.2.1.12  src/bos/usr/lib/security/aixpert/scripts/viosecureall.xml, aixpert, bos72Q, q2019_31A8 7/30/19 10:35:04        COMPONENT_NAME:   (AIXPERT) aixpertall.xml     FUNCTIONS: ...

Be careful if you are planning to migrate a db2 system from one server to another with different disks on AIX. DB2 v10 only support block disk sizes of 512, not possible to change. Only DB2 v11.5 support, so you either will need disks with blocks of 512 or you will need upgrade to this new version. On AIX if you have a RAID system with 4K disk it will create a final disk with 4K block size, is not possible to change. Cause DB2 up to v10.5: only supports file system or devices with Block and Sector Sizes of 512 bytes DB2 v11.1 M4 FP4: Technical preview for 4KB sector size for non-production systems via DB2 registry variable DB2_4K_DEVICE_SUPPORT DB2 v11.5: Supports 4KB sector size Click here for more information from IBM.

mount: 1831-011 access denied for xx.xx.xx.xx:/nim/mksyb mount: 1831-008 giving up on: XX.XX.XX.XX:/nim/folder The file access permissions do not allow the specified action. If you get the error above on AIX, try to use the server name to mount instead the IP address. I faced this strange situation on AIX, besides was working fine on another server with another nim, in others I was unable to mount the remove folder using the IP address. /etc/exports was ok, equal the other NIM. client and server can see each other. So the solution was put the NIM server name and IP on the /etc/hosts and try again.

Right, if you read my last post about how to overcome a problem with VIOs upgrade I have bad news for you. Like I showed in the last post, the update will fail because the fileset bos.alt_disk_install.boot_images, the fileset installed in your VIOs SHOULD be a version older than the on the VIOs 3.1 mksysb image, if you try run VIOs upgrade, the upgrade will fail. I faced this situation: Installed VIOs - 2.2.6.41, released on May/2019 The mksysb image that I extracted from the VIOs 3.1 dvd was from 2018. Upgraded failed, because as you can see the fileset on the VIOs 3.1 dvd was oldest than the current VIOs version. To overcome this I was obligated get a more recent VIOs 3.1 iso to create the mksysb, the most recent version now was from November/2019, so the fileset on the DVD iso was more recent than the installed on the VIOs. With that the installation performed fine as expected. But if you have a much more recent VIOs and is not able to get a VIOs 3.1 iso more recent than your curren...