The short answer to that question is “no”, but I’ll take the opportunity to explain why that is so here.
To run Atlas on any one of 20 different operating systems and/or Linux distros, you first obtain the atlas shell script with a command such as:
wget https://bit.do/dizatlas -O atlas.sh
Wget is an ancient (well, 1996… but that’s ancient in Internet years!) utility that simply fetches data from a web server. The web server in question is a little obfuscated by that short-form “bit.do” URL shown in the above command -but it’s actually my own web server, based in Paris, that hosts dizwell, diznix and some other websites I dabble with from time to time. As I say, wget has zero problem fetching the atlas script contents when told to do so on 20 different distros and OSes.
But, uniquely, on proper Solaris (in this case, 11.3), this happens:
The important bit there is “sslv3 alert handshake failure“: it means that Solaris’ version of wget is built to use the sslv3 protocol, and my web server doesn’t support that. Quite what the version of wget used by OpenIndiana, Ubuntu, Red Hat, etc etc ad infinitum is using to connect to my web server, I really have no idea. But whatever those other wget versions are using, it works happily! Only Solaris uses a wget configured in a way that doesn’t.
Now I respect Solaris’ “bullet-proof” nature, so I rather suspect that it’s my web server configuration that is at fault here, rather than Solaris. But I’m not re-configuring my entire server just because one O/S can’t handle it!
Anyway, Solaris’ inability to fetch stuff from my web server means Atlas falls at the first hurdle: you can’t even download the script to it in the first place! But suppose you persevered and somehow managed to download the relevant file to a Solaris machine via a web browser or some other technique… surely it would work then? Sort of… except that you would then fall at the second hurdle -which is that the atlas script expects to be able to download -using wget- a second script. Since that will fail too, for the same sslv3 reason described above, the entire thing collapses in a heap without configuring a thing on your Solaris box! 🙁
This is annoying!
So I resolved the matter by the simple expedient of storing a copy of the atlas script at Dropbox: Solaris’ version of wget is happy to negotiate a suitable connection with their servers, so a wget from there works fine. Similarly, if I rejig things slightly, the second script download works. And Lo! It then becomes trivially easy to run Atlas on Solaris 11.3 after all. Once you do, Oracle 12c R1 and R2 both install without incident or error.
So the rather longer answer to my original reader’s question is: Atlas didn’t run on proper Solaris, for abstruse technical reasons to do with encryption protocols, secret handshakes and the like… but now it does:
Obviously, I will alter the Atlas documentation again to take account of this new capability (which may take a day or two), but the quick instructions are:
wget https://bit.do/dizatlas2 -O atlas.sh chmod +x atlas.sh ./atlas
Note the use of dizatlas2 in that first wget command. That forces wget to talk to the Dropbox copy of Atlas, not the original as stored on my own server. I dislike needing to have copies of things in two entirely independent locations like this (it makes synchronizing the two repositories more difficult than it should be), but it’s the quickest solution for now: since you’ve pointed to the Dropbox repository, the wget command will succeed in fetching the file -and the script will similarly succeed in fetching the second file it needs to do its configuration work.
No other OS or distro needs -or indeed should– use this dizatlas2 respository: it’s only ever useful and required for Solaris 11.