Yesterday my son asked for help to open dds files in Photoshop. After some googling, I found this NVIDIA plugin for Photoshop and some articles, which complained that it does not work with Photoshop CS4 64bit. To solve this problem it was necessary to understand two things: that when 64bit version of Photoshop was installed, 32bit version also was installed, and that NVIDIA DDS plugin put the dds.8bi file to C:\Program Files\Adobe\Adobe Photoshop CS4 (64 Bit)\Plug-ins\File Formats folder.
So, to open dds files in Photoshop:
- download and install this NVIDIA plugin for Photoshop;
- copy dds.8bi file from
C:\Program Files\Adobe\Adobe Photoshop CS4 (64 Bit)\Plug-ins\File Formats folder to C:\Program Files (x86)\Adobe\Adobe Photoshop CS4\Plug-ins\File Formats folder;
- run 32bit Photoshop version from
C:\Program Files (x86)\Adobe\Adobe Photoshop CS4\
Hope this helps someone.
You may experience this problem, when can’t run TIBCO Administrator, Hawk, BW process or any other TIBCO component. In log files you can find messages related to OpenSSL libraries libeay32.dll and ssleay32.dll. The reason is that TIBCO messaging components use OpenSSL, but other applications may also use OpenSSL and have already installed these dlls in C:\WINDOWS\System32 or C:\WINDOWS\SysWOW64 depending on the platform.
When you start the application, it unsuccessful attempts to find dll files near the binary, then tries to find in the System32 folder. But dlls from other version of OpenSSL are there. Your application will use it, instead correct version from TIBCO Rendezvous bin folder for example, even you have this folder in the PATH. TIBCO product can’t call the necessary functions, gives an error and stops working.
Solution is take libeay32.dll and ssleay32.dll from TIBCO Rendezvous bin folder to the bin folders of every installed TIBCO component. Or just copy and replace to C:\WINDOWS\System32 or C:\WINDOWS\SysWOW64.
For all lovers of TIBCO, who is looking for the best web hosting: $90 discount DreamHost promo code is “TIBCOADMIN“.
DreamHost offers professional unlimited shared and vps hosting since 1997. I use their services for a year and I can recommend to everybody as a reliable partner. Features such as their own great Web Panel, Unlimited Policy, DreamHost PS, SSH access and so on meet all the requirements for a professional web hosting.
Sure you will be completely satisfied!
Here are my notes applicable for Solaris 10. First of all install latest patches – a lot of related things fixed (but new bugs may appear :))
- Synchronize the system clock with AD server
domain ntp server(s) must be in /etc/inet/ntp.conf
then restart ntp daemon svcadm restart /network/ntp
- Solaris server must have a record in the DNS
- Domain name and name servers (DNS servers) must be in
/etc/resolv.conf
- In the
/etc/nsswitch.conf file dns and files must be specified for hosts and ipnodes
...
hosts: dns files
ipnodes: dns files
...
- In the
/etc/nodename and /etc/hostname.<nic> files host name must be specified only, not a fully qualified domain name
- Run adjoin script. You can find it here. It will:
- auto-detects the Active Directory domain controllers
- creates a machine account (also called a Computer object) for the Solaris host in Active Directory and generates a random password for this account
- configures the Solaris host as a Kerberos client of the Active Directory domain controller by using the
/etc/krb5/krb5.conf file
- configures the
/etc/krb5/krb5.keytab file on the Solaris host by using the keys for the machine account (also called host credentials)
Execute adjoin script with following options:
./adjoin -d <domain_name> -p <administrator_principal> -f -x
where -f to delete any pre-existing computer account for this host and -x to debug output.
If your domain if geographically distributed with a lot of domain controllers (DC), script can detect inappropriate controllers. Just before entering admin password, check prepared adjoin-krb5.conf.XXXXXX file in the /tmp folder and remove unnecessary controllers from it.
Adjoin script can stop work with pkcs11_kernel.so syntax error on some SUN servers:
+ ./adjoin[859]: /usr/lib/security/$ISA/pkcs11_kernel.so:: syntax error
Then all you need is just to temporary rename this file and execute adjoin again
mv /usr/lib/security/$ISA/pkcs11_kernel.so /usr/lib/security/$ISA/pkcs11_kernel.so.orig
when adjoin finished successfully, rename it back
- Run ldapsearch and klist to check Kerberos
ldapsearch -R -T -h dc1.xxxxxx.com -o authzid= -o mech=gssapi -b CN=Computers,DC=xxxxxx,DC=com -s sub cn=<computer_name>
klist
klist -e -k /etc/krb5/krb5.keytab
- Enable dns client and cache daemons
svcadm enable /network/dns/client
svcadm enable /system/name-service-cache
- In the
/etc/nsswitch.ldap file dns and files must be specified for hosts and ipnodes
...
hosts: dns files
ipnodes: dns files
...
- Set up a server as a client of an LDAP. Execute ldapclient
ldapclient -v manual \
-a credentialLevel=self \
-a authenticationMethod=sasl/gssapi \
-a defaultSearchBase=dc=xxxxxx,dc=com \
-a defaultSearchScope=sub \
-a domainName=xxxxxx.com \
-a defaultServerList="dc1.xxxxxx.com dc2.xxxxxx.com dc3.xxxxxx.com" \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor="passwd:ou=Accounts,ou=European office,dc=xxxxxx,dc=com?sub;ou=Accounts,ou=American Office,dc=xxxxxx,dc=com?sub" \
-a serviceSearchDescriptor=group:ou=Groups,dc=xxxxxx,dc=com?sub
ldapclient should finish without errors. To check use ldapclient list
- Edit the
/etc/nsswitch.conf file: files and ldap must be specified for passwd and group only
...
passwd: files ldap
group: files ldap
hosts: dns files
ipnodes: dns files
networks: files
protocols: files
...
remove ldap from everywhere else
- Restart LDAP client
svcadm restart /network/ldap/client
- Add pam_krb5.so.1 in the
/etc/pam.conf file
...
login auth sufficient pam_krb5.so.1
krlogin auth required pam_krb5.so.1
krsh auth required pam_krb5.so.1
ktelnet auth required pam_krb5.so.1
other auth sufficient pam_krb5.so.1
other account required pam_krb5.so.1
other password sufficient pam_krb5.so.1
...
To ensure that users could login on the host under their AD accounts, accounts in AD must have following additional attributes:
uid the same as sAMAccountName
uidNumber unique number
gidNumber number
unixHomeDirectory for example /tmp
loginShell for example /usr/bin/bash or /bin/false
To check it use getent or ldapsearch
getent passwd <uid>
ldapsearch -R -T -h dc1.xxxxxx.com -b "ou=Accounts,ou=American Office,dc=xxxxxx,dc=com" -o mech=gssapi -o authzid='' "uid=<uid>"
If you would like read more: link to SUN’s article “Using Kerberos to Authenticate a Solaris 10 OS LDAP Client With Microsoft Active Directory”.
TIBCO Rendezvous is multicast-based messaging. Network Load Balancing (NLB) is a way to configure a pool of machines so they take turns responding to requests. It’s commonly implemented in server farms: identically configured machines that spread out the load for a web site or work as terminal services cluster.
Task was to cross both of these things – Rendezvous based application on servers in MS NLB terminal services cluster. I’ve done some tests using different settings, but the result was an inappropriate. I received RV messages only on one server or one message on the first server, next message on second, and so on, it depend on “Filtering mode”. NLB for multicast packets works even better than I would like! But users of an application work on every server and need all messages delivered to all users on all servers.
What happens with every frame that the Network Load Balancing driver (wlbs.sys) receives is:
- on every node wlbs.sys checks if the received packet is send to a virtual IP
- on every node wlbs.sys checks the source IP and port
- one node decides to accept the packet and passes it up to the TCP/IP driver
- all other nodes drop the packet
The issue is that there is no special treatment for multicast IPs. NLB driver treats them like every other IP that is not the dedicated IP of that machine.
What are the possible solutions?
- Receive the IP multicast traffic over a NIC where no NLB is bound to. Additional NIC in every server.
- Use TCP connection to remote Rendezvous daemon (rvd). Daemon parameter in RV transport:
-daemon "tcp:remotemachine:7500"
- Use local Rendezvous routing daemon (rvrd) instead of rvd. It requires rvrd on every terminal server and additional rvrd somewhere in the network.
If you would like read more, here is the list of clustering and high availability cluster resources from MS.
Yesterday TIBCO announced vulnerability in TIBCO Runtime Agent (TRA). To be more specific, in TIBCO Domain Utility (domainutility and domainutilitycmd). To say even more specifically, vulnerability is that the local users (whether they are on your server?) have read access to the properties files where administration domain credentials are stored. Not in clear text, by the way. Here is the advisory.
Here is the list of all security advisories for TIBCO products.
I like TIBCO.
