New users in Sol­aris 10 branded zones on Sol­aris 11 not handled auto­mat­ic­ally

A col­league no­ticed that on a Sol­aris 11 sys­tem a Sol­aris 10 branded zone “gains” two new dae­mons which are run­ning with UID 16 and 17. Those users are not auto­mat­ic­ally ad­ded to /​etc/​passwd, /​etc/​shadow (and /​etc/​group)… at least not when the zones are im­por­ted from an ex­ist­ing Sol­aris 10 zone.

I ad­ded the two users (net­adm, netcfg) and the group (net­adm) to the Sol­aris 10 branded zones by hand (copy&paste of the lines in /​etc/​passwd, /​etc/​shadow, /​etc/​group + run pw­conv) for our few Sol­aris 10 branded zones on Sol­aris 11.

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

In­crease of DNS re­quests after a crit­ical patch up­date of Sol­aris 10

Some weeks ago we in­stalled crit­ical patch up­dates (CPU) on a Sol­aris 10 sys­tem (in­ternal sys­tem, a year of CPU to in­stall, noth­ing in it af­fect­ing us or was con­sidered a se­cur­ity risk, we de­cided to ap­ply this one re­gard­less to not fall be­hind too much). Af­ter­wards we no­ticed that two zones are do­ing a lot of DNS re­quests. We no­ticed this already be­fore the zones went into pro­duc­tion and we con­figured a pos­it­ive time to live in nscd.conf for “hosts”. Ad­di­tion­ally we no­ticed a lot of DNS re­quests for IPv6 ad­dresses (AAAA look­ups), while ab­so­lutely no IPv6 ad­dress is con­figured in the zones (not even for loc­al­host… and those are ex­clus­ive IP zones). Ap­par­ently with one of the patches in the CPU the be­ha­viour changed re­gard­ing the cach­ing, I am not sure if we had the AAAA look­ups be­fore.

Today I got some time to de­bug this. After adding cach­ing of “ipnodes” in ad­di­tion to “hosts” (and I con­figured a neg­at­ive time to live for both at the same time), the DNS re­quests came down to a sane amount.

For the AAAA look­ups I have not found a solu­tion. By my read­ing of the doc­u­ment­a­tion I would as­sume there are not IPv6 DNS look­ups if there is not IPv6 ad­dress con­figured.

Status crypto cards HOWTO: prob­lems with the card reader (sup­port could be bet­ter)

After hours (spread over weeks) I come to the con­clu­sion that there is a lot of po­ten­tial to im­prove the doc­u­ment­a­tion of card read­ers (but I doubt the card reader vendors will do it) and of the pcsc doc­u­ment­a­tion. It is not easy to ar­rive at a point where you un­der­stand everything. The com­pat­ib­il­ity list does not help much, as the card read­ers are partly past their end of life and the mod­els which re­place them are not lis­ted. Re­spect­ively the one I bought does not sup­port all the fea­tures I need. I even por­ted the driver to FreeBSD (not com­mit­ted, I wanted to test everything first) and a lot of stuff works, but one crit­ical part is that I can not store a cer­ti­fic­ate on the crypto card as the card reader or the driver  does not sup­port ex­ten­ded AP­DUs (needed to trans­fer more than 255 bytes to the card reader).

Well, the status so far:

  • I have a HOWTO what to in­stall to use crypto cards in FreeBSD
  • I have a HOWOT what to in­stall /​ con­fig­ure in Win­dows
  • I have a HOWTO re­gard­ing cre­at­ing keys on a open­pgp v2 card and how to use this key with ssh on FreeBSD (or any other unix-​like OS which can run pcsc)
  • I have a card reader which does not sup­port ex­ten­ded AP­DUs
  • I want to make sure what I write in the HOW­TOs is also suit­able for the use with Win­dows /​ PuTTY
  • it seems Win­dows needs a cer­ti­fic­ate and not only a key when us­ing the Win­dows CAPI (us­ing the vendor sup­plied card reader driver) in PuTTY-​CSC (works at work with a USB token)
  • the pcsc pkcs11 Win­dows DLL is not suit­able yet for use on Win­dows 8 64bit
  • I con­tac­ted the card reader vendor if the card reader or the driver is the prob­lem re­gard­ing the ex­ten­ded AP­DUs
  • I found prob­lems in gpg4win /​ pcsc on Win­dows 8
  • I have send some money to the de­velopers of gpg4win to sup­port their work (if you use gnupg on Win­dows, try to send a few units of money to them, the work stag­nated as they need to spend their time for paid work)

So either I need a new card reader, or have to wait for an up­date of the linux driver of the vendor… which prob­ably means it may be a lot faster to buy a new card reader. When look­ing for one with at least a PIN pad, I either do not find any­thing which is lis­ted as sup­por­ted by pcsc on the vendor pages (it is in­cred­ible how hard it is to nav­ig­ate the web­sites of some com­pan­ies… a lot of buzzwords but no way to get to the real products), or they only list up­dated mod­els where I do not know if they will work.

When I have some­thing which works with FreeBSD and Win­dows, I will pub­lish all the HOW­TOs here at once.

Com­plete net­work loss on Sol­aris 10u10 CPU 2012-​10 on vir­tu­al­ized T4-​2

The prob­lem I see at work: A T4-​2 with 3 guest LDOMs, vir­tu­al­ized disks and net­works lost the com­plete net­work con­nectiv­ity “out of the blue” once, and maybe “sporadic” dir­ectly after a cold boot. After a lot of dis­cus­sion with Or­acle, I have the im­pres­sion that we have two prob­lems here.

1st prob­lem:
Total net­work loss of the ma­chine (no zone or guest LDOM or the primary LDOM was able to have re­ceive or send IP pack­ets). This happened once. No idea how to re­pro­duce it. In the logs we see the mes­sage “[ID 920994 kern.warning] WARNING: vnetX: ex­ceeded num­ber of per­mit­ted hand­shake at­tempts (5) on chan­nel xxx”. Ac­cord­ing to Or­acle this is sup­posed to be fixed in 148677 – 01 which will come with Sol­aris 10u11. They sug­ges­ted to use a vsw in­ter­face in­stead of a vnet in­ter­face on the primary do­main to at least lower the prob­ab­il­ity of this prob­lem hit­ting us. They were not able to tell us how to re­pro­duce the prob­lem (seems to be a race con­di­tion, at least I get this im­pres­sion based upon the de­scrip­tion of the Or­acle en­gin­eer hand­ling the SR). Only a re­boot helped to get the prob­lem solved. I was told we are the only cli­ent which re­por­ted this kind of prob­lem, the patch for this prob­lem is based upon an in­ternal bu­gre­port from in­ternal tests.

2nd prob­lem:
After cold boots some­times some ma­chines (not all) are not able to con­nect to an IP on the T4. A re­boot helps, as does re­mov­ing an in­ter­face from an ag­greg­ate and dir­ectly adding it again (see be­low for the sys­tem con­fig). To try to re­pro­duce the prob­lem, we did a lot of warm re­boots of the primary do­main, and the prob­lem never showed up. We did some cold re­boots, and the prob­lem showed up once.

In case someone else sees one of those prob­lems on his ma­chines too, please get in con­tact with me to see what we have in com­mon to try to track this down fur­ther and to share info which may help in maybe re­pro­du­cing the prob­lems.

Sys­tem setup:

  • T4-​2 with 4 HBAs and 8 NICs (4 * igb on-​board, 4 * nxge on ad­di­tional net­work card)
  • 3 guest LDOMs and one io+control do­main (both in the primary do­main)
  • the guest LDOMs use SAN disks over the 4 HBAs
  • the primary do­main uses a mirrored zpool on SSDs
  • 5 vswitch in the hy­per­visor
  • 4 ag­greg­ates (aggr1 – aggr4 with L2-​policy), each one with one igb and one nxge NIC
  • each ag­greg­ate is con­nec­ted to a sep­ar­ate vswitch (the 5th vswitch is for machine-​internal com­mu­nic­a­tion)
  • each guest LDOM has three vnets, each vnets con­nec­ted to a vswitch (1 guest LDOM has aggr1+2 only for zones (via vnets), 2 guest LDOMs have aggr 3+4 only for zones (via vnets), and all LDOMs have aggr2+3 (via vnets) for global-​zone com­mu­nic­a­tion, all LDOMs are ad­di­tion­ally con­nec­ted to the machine-​internal-​only vswitch via the 3rd vnet)
  • primary do­main uses 2 vnets con­nec­ted to the vswitch which is con­nec­ted to aggr2 and aggr3 (con­sist­ency with the other LDOMs on this ma­chine) and has no zones
  • this means each en­tity (primary do­main, guest LDOMs and each zone) has two vnets in and those two vnets are con­figured in a link-​based IPMP setup (vnet-linkprop=phys-state)
  • each vnet has VLAN tag­ging con­figured in the hy­per­visor (with the zones be­ing in dif­fer­ent VLANs than the LDOMs)

The pro­posed change by Or­acle is to re­place the 2 vnet in­ter­faces in the primary do­main with 2 vsw in­ter­faces (which means to do VLAN tag­ging in the primary do­main dir­ectly in­stead of in the vnet con­fig). To have IPMP work­ing this means to have vsw-linkprop=phys-state. We have two sys­tems with the same setup, on one sys­tem we already changed this and it is work­ing as be­fore. As we don’t know how to re­pro­duce the 1st prob­lem, we don’t know if the prob­lem is fixed or not, re­spect­ively what the prob­ab­il­ity is to get hit again by this prob­lem.

Ideas /​ sug­ges­tions /​ info wel­come.

Which crypto card to use with FreeBSD (ssh/​gpg)

The re­cent se­cur­ity in­cid­ent triggered a dis­cus­sion how to se­cure ssh/​gpg keys.

One way I want to fo­cus on here (be­cause it is the way I want to use at home), is to store the keys on a crypto card. I did some re­search for suit­able crypto cards and found one which is called Fei­tian PKI Smart­card, and one which is called Open­PGP card. The Open­PGP card also ex­ists in a USB ver­sion (ba­sic­ally a small ver­sion of the card is already in­teg­rated into a small USB card reader).

The Fei­tian card is re­por­ted to be able to handle RSA keys upto 2048 bits. They do not seem to handle DSA (or ECDSA) keys. The smart­card quick starter guide they have  (the Tun­ing smart­card file sys­tem part) tells how to change the para­met­ers of the card to store upto 9 keys on it.

The spec of the Open­PGP card tells that it sup­ports RSA keys upto 3072 bits, but there are re­ports that it is able to handle RSA keys upto 4096 bits (you need to have at least GPG 2.0.18 to handle that big keys on the crypto card). It looks to me like the card is not handle DSA (or ECDSA) cards. There are only slots for upto 3 keys on it.

If I go this way, I would also need a card reader. It seems a class 3 one (hard­ware PIN pad and dis­play) would be the most “future-​proof” way to go ahead. I found a Reiner SCT cy­ber­Jack secoder card reader, which is be­lieved to be sup­por­ted by OpenSC and seems to be a good bal­ance between cost and fea­tures of the Reiner SCT card read­ers.

If any­one read­ing this can sug­gest a bet­ter crypto card (keys upto 4096 bits, more than 3 slots, and/​or DSA/​ECDSA  sup­port), or a bet­ter card reader, or has any prac­tical ex­per­i­ence with any of those com­pon­ents on FreeBSD, please add a com­ment.