Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
I kind of have to second that this is a bit of a TALL order with Dovecot. Dovecot can be configured SO many different ways, it's unbelievable. If memory serves me correctly, when I installed it on Red Hat EL6.2 a year or so ago, I don't think it worked without being manually configured there, either. I had to go in and edit the config files by hand before it would work. And I think I even had to search through Dovecot's website for info about settings that it simply wouldn't run without. Some of those settings were from changes made between Dovecot 1.2 and 2.1 that never quite made it into the files they distribute. So, if it isn't even there, it's certainly not the distro's fault ! And when I installed Dovecot from source on OI a few months ago, they still hadn't made it in. Just for what it's worth... Oh, and if you read through some of Dovecot's own mailing list, there doesn't seem to be a real great shortage of people who don't consider 2.1 particularly stable. That's something you might want to consider, too. Apparently, Timo made some people a little less than happy with the new version of Dovecot. HTH On Feb 25, 2013, at 7:07 AM, Hans J. Albertsson wrote: > I generally agree with your attitude: for dovecot that is a TALL order, and > my Windows experience so far is that similar mishaps occur in that universe, > too. > > Down the dovecot road there might be some sort of future setup tool, that > asks the installing user what she intends to use dovecot for and produces > some sort of boilerplate conf tree, and asks about what certs to use and > whetever else seems obvious and asks the user to select one config type out > of a few. > > . > > Today there isn't. > > > On 2013-02-25 14:54, Dmitry Kozhinov wrote: >> I am not accusing anyone, but just trying to understand: >> Why not make a package so that it would run out-of-the-box? >> >> When you buy a car, imagine that engine would not start unless you: >> - Kick right rear tire; >> - Open and close trunk lid; >> - You name what else... >> >> Maybe those who know what-to-do (to simply get a package running) feel >> themselves gurus, which is cool, but obviously making things go this way >> condemns the great OS into extinction. >> >> >> >> ___ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Unable to load RAID driver
The latest phase is 15. I would try that, before loading an older version. http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapt ers%20Common%20Files/SAS_SATA_6G_P15/9211_8i_Package_P15_IR_IT_Firmware_BIOS _for_MSDOS_Windows.zip j. -Original Message- From: Lawrence [mailto:lawren_g...@yahoo.com] Sent: Monday, February 25, 2013 7:28 PM To: Discussion list for OpenIndiana Subject: Re: [OpenIndiana-discuss] Unable to load RAID driver Hi Saso, Would you be able to show me where to download that particular firmware? I can only find this version on the LSI website 9211_8i_Package_P13.5_IR_IT_Firmware_BIOS_for_MSDOS_Windows Description: Package for Firmware and BIOS Upgrade on MSDOS and Windows Version: 13.00.66.00 Size: 1.7M Regards. From: Sašo Kiselkov To: openindiana-discuss@openindiana.org Sent: Tuesday, February 26, 2013 1:29 AM Subject: Re: [OpenIndiana-discuss] Unable to load RAID driver On 02/25/2013 05:25 PM, Lawrence Giam wrote: > Hi Saso, > > The system is not loading the driver correctly. After booting into OI, doing a prtconf | less shows the mpt_sas drivers not loaded. When I tried to manually add, it show the error below. What does "sas2flash -listall" report? I'm currently running these firmware revisions without any trouble: # ./sas2flash -listall ..[snip].. Ctlr FW Ver NVDATA x86-BIOS --- SAS2008(B2) 13.00.57.00 0d.43.00.02 07.25.00.00 SAS2008(B2) 07.15.08.00 07.00.00.19 07.11.10.00 Perhaps you can try and reflash to these firmware revisions and retest to see if the trouble isn't only caused by a "too new" firmware issue. Cheers, -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Unable to load RAID driver
Hi Saso, Would you be able to show me where to download that particular firmware? I can only find this version on the LSI website 9211_8i_Package_P13.5_IR_IT_Firmware_BIOS_for_MSDOS_Windows Description: Package for Firmware and BIOS Upgrade on MSDOS and Windows Version: 13.00.66.00 Size: 1.7M Regards. From: Sašo Kiselkov To: openindiana-discuss@openindiana.org Sent: Tuesday, February 26, 2013 1:29 AM Subject: Re: [OpenIndiana-discuss] Unable to load RAID driver On 02/25/2013 05:25 PM, Lawrence Giam wrote: > Hi Saso, > > The system is not loading the driver correctly. After booting into OI, doing > a prtconf | less shows the mpt_sas drivers not loaded. When I tried to > manually add, it show the error below. What does "sas2flash -listall" report? I'm currently running these firmware revisions without any trouble: # ./sas2flash -listall ..[snip].. Ctlr FW Ver NVDATA x86-BIOS --- SAS2008(B2) 13.00.57.00 0d.43.00.02 07.25.00.00 SAS2008(B2) 07.15.08.00 07.00.00.19 07.11.10.00 Perhaps you can try and reflash to these firmware revisions and retest to see if the trouble isn't only caused by a "too new" firmware issue. Cheers, -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
> Are you saying there's another copy besides idmap.db? I'd not seen evidence > of that. No, but even if an object is already in the cache, it still seems to be updating the UID. It doesn't seem to be the case that an entry in the idmap cache is a static entry. Either that or the cache timeout settings just aren't actually being used correctly (it is odd that this is changing every 10 minutes - which is the default cache time). > The hard part is finding one person who understands the internals of 3 > systems well. They shouldn't really need to; OS X uses LDAP natively if you use OS X Server (uncommon) so that would just work straight away, no problems there. In terms of what we though most of the time Mac users will be accessing with Active Directory credentials (because that's what enterprises tend to use these days). > Given a program which will run on OI and return a text file w/ the current > set of user IDs in the host domain, the rest is trivial. It's a non-blocking > fork-exec of the update program. On a rare event it's as non-invasive as it > gets. The thing is that the whole problem with Active Directory is that (natively) it doesn't have user IDs, it has SIDs - so you need to look up the SID and then generate a UID. This is what winbind and Mac OS X do and importantly their mappings are automatically generated, but static. So if user jbloggs logs into an OS X system bound to AD, he gets a UID generated for him, and that will always be his UID (on a Mac bound to that AD - it's generated based on the SID). The problem with ephemeral IDs is the ephemeral part! If you could just have an idmap setting which was basically: use IDs 5-75000 for AD users that would solve the problem, once an AD user access the system they get assigned a fixed UID. As mentioned OS X is slightly more clever as the UID is generated procedurally from information from the AD, but that would be nice, rather than critical. Basically if you could have idmap so it would do: S-1-5-21-422489907-454740634-3148902543 >> 2147483650 with the Windows SID on the left and the UNIX UID on the right, and have that not change, that would be it. You can do that now by doing name based mappings, so you can get: S-1-5-21-422489907-454740634-3148902543 >> name-of-local-user but it isn't automatic and it's a bit inflexible. You could write a bash script that did: - LDAP query of AD to get user and group names - Create matching users and groups on Oi system - Create static maps between AD users/groups and Oi users/groups I wouldn't think that would be fast though, and I wouldn't know the best way of triggering it. James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
--- On Mon, 2/25/13, James Relph wrote: > From: James Relph > Subject: Re: [OpenIndiana-discuss] idmap timeout > To: "Discussion list for OpenIndiana" > Date: Monday, February 25, 2013, 4:47 PM > > > Unless I've badly misunderstood what I've read it can > do that now. Of course, comments and code are not > always in agreement. Or perhaps the more common, > "However, if you did that then, you can't do this now." > > The thing is that there doesn't seem to be anything anywhere > that actually says "ephemeral IDs will persist". > There's a cache, which you can change the timeouts for, but > from what I can see it either updates the cache anyway, or > updates the UID of cached objects. Are you saying there's another copy besides idmap.db? I'd not seen evidence of that. I *think* the idea is you scan a list returned by the database and check the expiration stamp of the items relative to the epoch. Negative items are ignored. The least positive entry is selected, and the loop sleeps on that timer. I'm sure there are subtleties I missed as I went pretty quickly. But it's a common pattern that fits the requirement. > > > Ignoring that the only limitation I see is what will > Windows & Mac OS reveal w/o requiring installing a > program. If OI can query the AD hosts, then idmap can > trigger an update on a fail of identifier lookup. > That's a pretty clean change. One function call in the > right place. > > It's getting someone who can write the function call that is > tricky! The hard part is finding one person who understands the internals of 3 systems well. Given a program which will run on OI and return a text file w/ the current set of user IDs in the host domain, the rest is trivial. It's a non-blocking fork-exec of the update program. On a rare event it's as non-invasive as it gets. An alternative would be to have Windows provide everything in a CIFS share and access that from idmap. That might be attractive from a security perspective if access can be tightly controlled. And of course, what does Mac OS do? Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
--- On Mon, 2/25/13, James Relph wrote: > From: James Relph > Subject: Re: [OpenIndiana-discuss] idmap timeout > To: "Discussion list for OpenIndiana" > Date: Monday, February 25, 2013, 3:18 PM > > I did think of that, but it's > things like triggering that, keeping it up to date (ie. when > users are removed from AD) and the rest, and I thought it > might become quite a big project really and something that > may be better written as some kind of alternate idmap option > (i.e. instead of just having static and ephemeral, have > static, ephemeral and cached - with cached basically being > automatically created user mappings). > > When I say cached I mean a cached copy of the users in AD > (with some ADs that could be a big ask though...). > > I added idmap dump -nv | grep james to the script, and I'm > getting effectively the same issue: > > 18:56:00 uid=2147508227 > gid=2147483650(Domain Users@themacplace.private) > 18:56:00 winuser:james@themacplace.private > == uid:2147508228 > 18:57:00 uid=2147508227 > gid=2147483650(Domain Users@themacplace.private) > 18:57:00 winuser:james@themacplace.private > == uid:2147508228 > 18:58:00 uid=2147508227 > gid=2147483650(Domain Users@themacplace.private) > 18:58:00 winuser:james@themacplace.private > == uid:2147508228 > 18:59:00 uid=2147508228(james@themacplace.private) > gid=2147483650(Domain Users@themacplace.private) > 18:59:00 winuser:james@themacplace.private > == uid:2147508229 > 19:00:00 uid=2147508228(james@themacplace.private) > gid=2147483650(Domain Users@themacplace.private) > 19:00:00 winuser:james@themacplace.private > == uid:2147508229 > 19:01:00 uid=2147508228 > gid=2147483650(Domain Users@themacplace.private) > 19:01:00 winuser:james@themacplace.private > == uid:2147508229 > > The id command seems to lag a little behind the idmap dump > command, I'm guessing a cached problem there. Still, > they do still keep changing... > Dump the database too. Do you suppose Windows could be resetting the connection? I'm generating ephemeral map entries that hang around in the tables. But I'm doing it on OI. No Windows. Maybe it's a signalling glitch. MS is using a reset operation as a keep alive? Wouldn't be the first time an interface got confused. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
> Unless I've badly misunderstood what I've read it can do that now. Of > course, comments and code are not always in agreement. Or perhaps the more > common, "However, if you did that then, you can't do this now." The thing is that there doesn't seem to be anything anywhere that actually says "ephemeral IDs will persist". There's a cache, which you can change the timeouts for, but from what I can see it either updates the cache anyway, or updates the UID of cached objects. > Ignoring that the only limitation I see is what will Windows & Mac OS reveal > w/o requiring installing a program. If OI can query the AD hosts, then idmap > can trigger an update on a fail of identifier lookup. That's a pretty clean > change. One function call in the right place. It's getting someone who can write the function call that is tricky! James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
--- On Mon, 2/25/13, James Relph wrote: > From: James Relph > Subject: Re: [OpenIndiana-discuss] idmap timeout > To: "Discussion list for OpenIndiana" > Date: Monday, February 25, 2013, 3:00 PM > > > Try modifying your cron job to do a: > > > > "idmap dump -nv" > > I'll add that in, see what drops out. > > > Writing a static set of name rules using awk should be > pretty trivial if one can query Windows and Mac OS for > authorized user name lists. Updating could be > triggered by a request that didn't have a mapping yet. > This would then all persist across boots. > > I did think of that, but it's things like triggering that, > keeping it up to date (ie. when users are removed from AD) > and the rest, and I thought it might become quite a big > project really and something that may be better written as > some kind of alternate idmap option (i.e. instead of just > having static and ephemeral, have static, ephemeral and > cached - with cached basically being automatically created > user mappings). > > To be fair if idmap was able to just use static mapping to a > range of IDs that would be good enough. Unless I've badly misunderstood what I've read it can do that now. Of course, comments and code are not always in agreement. Or perhaps the more common, "However, if you did that then, you can't do this now." Ignoring that the only limitation I see is what will Windows & Mac OS reveal w/o requiring installing a program. If OI can query the AD hosts, then idmap can trigger an update on a fail of identifier lookup. That's a pretty clean change. One function call in the right place. Or update every 5 minutes and there's no change needed. Just a cron job. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] time-slider
I haven't seen that error, but I would guess that the time-slider service specified a user of "zfssnap", and something had problems while trying to use that user. On my system, zfssnap is a role: in /etc/user_attr: zfssnaptype=role;auths=solaris.smf.manage.zfs-auto-snapshot;profiles=ZFS File System Management and time-slider is set to use it: $ svcprop time-slider | grep user ... start/user astring zfssnap stop/user astring zfssnap refresh/user astring zfssnap Hopefully this helps you figure out what might be wrong (did you delete the zfssnap role, or otherwise modify it?). Tim On Mon, Feb 25, 2013 at 11:47 AM, wrote: > Hello everybody, > > I have some problem with the time-slider in OI 151a7 (no GUI): > > It went to maintenance mode at some point in time, and I was not able to > bring it up again since then. > > I already restarted dbus and rebooted, but the time-slider remains in > maintenence mode. > > The error message I see is: "Could not interpret "user" property value > "zfssnap", error 2." > > > any suggestions? > > > Carsten > > > > -- > system-admin.info > IT-Systemberatung, Infrastruktur, Netze > Carsten John > Cruesemannallee 13 > 28213 Bremen > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
> I did think of that, but it's things like triggering that, keeping it up to > date (ie. when users are removed from AD) and the rest, and I thought it > might become quite a big project really and something that may be better > written as some kind of alternate idmap option (i.e. instead of just having > static and ephemeral, have static, ephemeral and cached - with cached > basically being automatically created user mappings). When I say cached I mean a cached copy of the users in AD (with some ADs that could be a big ask though...). I added idmap dump -nv | grep james to the script, and I'm getting effectively the same issue: 18:56:00 uid=2147508227 gid=2147483650(Domain Users@themacplace.private) 18:56:00 winuser:james@themacplace.private== uid:2147508228 18:57:00 uid=2147508227 gid=2147483650(Domain Users@themacplace.private) 18:57:00 winuser:james@themacplace.private== uid:2147508228 18:58:00 uid=2147508227 gid=2147483650(Domain Users@themacplace.private) 18:58:00 winuser:james@themacplace.private== uid:2147508228 18:59:00 uid=2147508228(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) 18:59:00 winuser:james@themacplace.private== uid:2147508229 19:00:00 uid=2147508228(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) 19:00:00 winuser:james@themacplace.private== uid:2147508229 19:01:00 uid=2147508228 gid=2147483650(Domain Users@themacplace.private) 19:01:00 winuser:james@themacplace.private== uid:2147508229 The id command seems to lag a little behind the idmap dump command, I'm guessing a cached problem there. Still, they do still keep changing... James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
> Try modifying your cron job to do a: > > "idmap dump -nv" I'll add that in, see what drops out. > Writing a static set of name rules using awk should be pretty trivial if one > can query Windows and Mac OS for authorized user name lists. Updating could > be triggered by a request that didn't have a mapping yet. This would then > all persist across boots. I did think of that, but it's things like triggering that, keeping it up to date (ie. when users are removed from AD) and the rest, and I thought it might become quite a big project really and something that may be better written as some kind of alternate idmap option (i.e. instead of just having static and ephemeral, have static, ephemeral and cached - with cached basically being automatically created user mappings). To be fair if idmap was able to just use static mapping to a range of IDs that would be good enough. James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
> FWIW "svcadm restart idmap" loads the new setting properly on oi_151a7 w/o an > "svcadm refresh idmap". Yep, didn't make any difference: 18:30:00 uid=2147508225(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) 18:31:00 uid=2147508225(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) 18:32:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:33:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:34:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:35:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:36:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:37:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:38:00 uid=2147508225 gid=2147483650(Domain Users@themacplace.private) 18:39:00 uid=2147508226(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
--- On Mon, 2/25/13, Jim Klimov wrote: > From: Jim Klimov > Subject: Re: [OpenIndiana-discuss] idmap timeout > To: openindiana-discuss@openindiana.org > Date: Monday, February 25, 2013, 2:27 PM > On 2013-02-25 21:12, James Relph > wrote: > >> Just in case, you also did "svcadm refresh idmap" > after changing SMF > >> service properties and before restarting the > service, right? ;) > > > > I think so, although you've got me wondering now. > Although saying that, it's appearing correctly in the idmap > database, so presumably I did and that should be in effect > anyway? > > Just in case, do it then - won't hurt. > I was bitten more than once that "svccfg" changes the SMF > definitions > database, but the running-config is stored in another SMF > database - > and the refresh action replicates the changed config bits. > Otherwise > even a reboot (IIRC) won't enable your most recent SMF > changes. > > I may be wrong though, and this may be experience from an > older distro > and not applicable to OI, but still... FWIW "svcadm restart idmap" loads the new setting properly on oi_151a7 w/o an "svcadm refresh idmap". Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
James, Try modifying your cron job to do a: "idmap dump -nv" each time it goes off. I am not seeing that output change, nor am I seeing the contents of idmap.db change over time as things expire. But they might be intended to remain to allow reconnections w/ the same mapping. Writing a static set of name rules using awk should be pretty trivial if one can query Windows and Mac OS for authorized user name lists. Updating could be triggered by a request that didn't have a mapping yet. This would then all persist across boots. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
On 2013-02-25 21:12, James Relph wrote: Just in case, you also did "svcadm refresh idmap" after changing SMF service properties and before restarting the service, right? ;) I think so, although you've got me wondering now. Although saying that, it's appearing correctly in the idmap database, so presumably I did and that should be in effect anyway? Just in case, do it then - won't hurt. I was bitten more than once that "svccfg" changes the SMF definitions database, but the running-config is stored in another SMF database - and the refresh action replicates the changed config bits. Otherwise even a reboot (IIRC) won't enable your most recent SMF changes. I may be wrong though, and this may be experience from an older distro and not applicable to OI, but still... //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
> Just in case, you also did "svcadm refresh idmap" after changing SMF > service properties and before restarting the service, right? ;) I think so, although you've got me wondering now. Although saying that, it's appearing correctly in the idmap database, so presumably I did and that should be in effect anyway? James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
On 2013-02-25 20:22, James Relph wrote: Also, did you "svcadm restart idmap" after setting the timeouts? Yep! Just in case, you also did "svcadm refresh idmap" after changing SMF service properties and before restarting the service, right? ;) //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SMF "svcadm restart-or-clear-or-start" action
On 2013-02-25 20:17, Peter Tribble wrote: On Mon, Feb 25, 2013 at 3:03 PM, Jim Klimov wrote: FWIW, I added this RFE to illumos bugtracker so it can be found by people looking to do simple useful quests and develop illumos: https://www.illumos.org/issues/3596 Looking at that, isn't the real meat of this just making enable do a clear if the service is in maintenance? After all, the manpage on my S10 system says for enable "For each service instance, the assigned restarter will try to bring it to the online state." Hm... possibly, at least if the docs say so and are not fulfilled ;) I know that I *wouldn't* want a forced enable to do a restart of an already running service. No, in fact that's what I would like it to do - and hence overloading the existing keywords is not an option in terms of backwards compat. Say, I'm reconfiguring some server service, i.e. Apache or a Sendmail. I changed the config, and I want to make sure that the service can start with it. And I want to type as little as possible into the shell too ;) So I'd go "svcadm kick sendmail" and not care if it ran or did not, if it was failed or not. As a result, if the current config is valid, the service should become online and having applied the new config. Thinking of it, the feature should also involve "svcadm refresh svcname" so that changed SMF settings would also get applied in one blow. And force-enabling an offline service doesn't really make sense. It's likely some other service that's causing the problem, the service that's offline probably is enabled. Okay, make it "enable -r" :-) But I am not sure it should be done by default. If the feature includes diags after startup, as detailed in the bugtracker, admin will be notified in his shell about the fact of failure to start the service and about possible reasons - i.e. disabled dependencies... //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
Hi Reg,
> svccfg -s svc:/system/idmap listprop "config/*"
config/list_size_limit count0
config/stabilityastring Unstable
config/value_authorization astring solaris.smf.value.idmap
config/machine_sid astring S-1-5-21-3389328288-2012474116-2712525247
config/domain_name astring themacplace.private
config/name_cache_timeout count31536000
config/id_cache_timeout count31536000
> Also, did you "svcadm restart idmap" after setting the timeouts?
Yep!
> What are you using to make the query in the cron job?
#/bin/bash
datestring=$(date +"%H:%M:%S")
userdata=$(/usr/bin/id james@themacplace.private)
echo "$datestring" " " "$userdata" >> /root/idtest.log
> Checking idmap.db per the notes in feature #677 shows the expiration time
> being set properly in the database in oi_151a7.
Yeah, I did that, and the expiration time did change:
INSERT INTO idmap_cache
VALUES('S-1-5-21-422489907-454740634-3148902543',1105,'themacplace.private','james','james',2147500059,NULL,1,1,1,1,4,NULL,NULL,NULL,NULL,NULL,NULL,0,1393348328)
The current epoch time is 1361813013, so 1393348328 - 1361813013 gives
31535315, so it looks like it's working absolutely fine in terms of changing
the settings, it just doesn't appear to be having much effect. I've left it
running and it's still doing it!
17:11:00 uid=2147500057 gid=2147483650(Domain Users@themacplace.private)
17:12:00 uid=2147500058(james@themacplace.private) gid=2147483650(Domain
Users@themacplace.private)
17:13:00 uid=2147500058(james@themacplace.private) gid=2147483650(Domain
Users@themacplace.private)
17:14:00 uid=2147500058(james@themacplace.private) gid=2147483650(Domain
Users@themacplace.private)
17:15:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:16:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:17:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:18:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:19:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:20:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:21:00 uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:22:00 uid=2147500059 gid=2147483650(Domain Users@themacplace.private)
17:23:00 uid=2147500059 gid=2147483650(Domain Users@themacplace.private)
17:24:00 uid=2147500059 gid=2147483650(Domain Users@themacplace.private)
Cheers,
James.
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SMF "svcadm restart-or-clear-or-start" action
On Mon, Feb 25, 2013 at 3:03 PM, Jim Klimov wrote: > FWIW, I added this RFE to illumos bugtracker so it can be found > by people looking to do simple useful quests and develop illumos: > https://www.illumos.org/issues/3596 Looking at that, isn't the real meat of this just making enable do a clear if the service is in maintenance? After all, the manpage on my S10 system says for enable "For each service instance, the assigned restarter will try to bring it to the online state." I know that I *wouldn't* want a forced enable to do a restart of an already running service. And force-enabling an offline service doesn't really make sense. It's likely some other service that's causing the problem, the service that's offline probably is enabled. Related to this, my biggest gripe with SMF is that if you do a restart and the stop method fails, it goes into maintenance without even attempting to run the start method. >> Hello all, >> >>While setting up systems there are occasions when an SMF service >> needs to be restarted - i.e. due to reconfiguration or its failure. >> The "svcadm restart" action only takes place for "online" services. >> >>I wonder if it is a reasonable RFE to add some command (and what >> should it be called?) to try to "kick" a service into "online" state >> from whatever starting situation. For an already "online" service >> this would act as a "restart", for an "offline" service this would >> be an "enable", and a service in "maintenance" this would "clear". >> >>This should likely do nothing with services in transitional state >> (currently becoming online or offline - though maybe request restart >> of the latter), and of course the action may fail again (likely into >> maintenance) if the service is still misconfigured. >> >>It is just annoying to have to verify the service's current state >> before "kicking" it, though I've spawned a simple admin-script on >> my systems to do this chore ;) >> >>I think the solution should be a part of the common SMF structure. >> >>And it is a bite-size task for any enthusiast, now that we have >> a few :) >> >> //Jim Klimov > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] idmap timeout
--- On Mon, 2/25/13, James Relph wrote: > From: James Relph > Subject: [OpenIndiana-discuss] idmap timeout > To: "Discussion list for OpenIndiana" > Date: Monday, February 25, 2013, 7:44 AM > Hi all, > > Another idmap issue! Just trying a new VM for some > troubleshooting and I can't seem to get the > name_cache_timeout and id_cache_timeout settings to work on > here. I've run: > > svccfg -s svc:/system/idmap setprop > config/name_cache_timeout=count: 31536000 > svccfg -s svc:/system/idmap setprop > config/id_cache_timeout=count: 31536000 > > but I'm still seeing UIDs changing every 10 minutes (cron > job here running an id to a file every minute): > > 13:05:00 uid=2147491845 > gid=2147483650(Domain Users@themacplace.private) > 13:06:00 uid=2147491845 > gid=2147483650(Domain Users@themacplace.private) > 13:07:00 uid=2147491845 > gid=2147483650(Domain Users@themacplace.private) > 13:08:00 uid=2147491845 > gid=2147483650(Domain Users@themacplace.private) > 13:09:00 uid=2147491845 > gid=2147483650(Domain Users@themacplace.private) > 13:10:00 uid=2147491845 > gid=2147483650(Domain Users@themacplace.private) > 13:11:00 uid=2147491846(james@themacplace.private) > gid=2147483650(Domain Users@themacplace.private) > 13:12:00 uid=2147491846(james@themacplace.private) > gid=2147483650(Domain Users@themacplace.private) > 13:13:00 uid=2147491846 > gid=2147483650(Domain Users@themacplace.private) > 13:14:00 uid=2147491846 > gid=2147483650(Domain Users@themacplace.private) > 13:15:00 uid=2147491846 > gid=2147483650(Domain Users@themacplace.private) > 13:16:00 uid=2147491846 > gid=2147483650(Domain Users@themacplace.private) > 13:17:00 uid=2147491846 > gid=2147483650(Domain Users@themacplace.private) > > Does anyone know if this is a bug, or expected > behaviour? Obviously doesn't affect CIFS at all, but > I'm trying to do some troubleshooting against another > service. What also seems a bit weird is the output > format of id changes when the id ticks over (adds the > username into brackets)? > What does svccfg -s svc:/system/idmap listprop "config/*" show after making the settings? Also, did you "svcadm restart idmap" after setting the timeouts? What are you using to make the query in the cron job? Checking idmap.db per the notes in feature #677 shows the expiration time being set properly in the database in oi_151a7. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] time-slider
Hello everybody, I have some problem with the time-slider in OI 151a7 (no GUI): It went to maintenance mode at some point in time, and I was not able to bring it up again since then. I already restarted dbus and rebooted, but the time-slider remains in maintenence mode. The error message I see is: "Could not interpret "user" property value "zfssnap", error 2." any suggestions? Carsten -- system-admin.info IT-Systemberatung, Infrastruktur, Netze Carsten John Cruesemannallee 13 28213 Bremen ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Unable to load RAID driver
On 02/25/2013 05:25 PM, Lawrence Giam wrote: > Hi Saso, > > The system is not loading the driver correctly. After booting into OI, doing > a prtconf | less shows the mpt_sas drivers not loaded. When I tried to > manually add, it show the error below. What does "sas2flash -listall" report? I'm currently running these firmware revisions without any trouble: # ./sas2flash -listall ..[snip].. Ctlr FW Ver NVDATAx86-BIOS --- SAS2008(B2) 13.00.57.000d.43.00.0207.25.00.00 SAS2008(B2) 07.15.08.0007.00.00.1907.11.10.00 Perhaps you can try and reflash to these firmware revisions and retest to see if the trouble isn't only caused by a "too new" firmware issue. Cheers, -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Unable to load RAID driver
Hi Saso, The system is not loading the driver correctly. After booting into OI, doing a prtconf | less shows the mpt_sas drivers not loaded. When I tried to manually add, it show the error below. Sent from my iPad On 25 Feb, 2013, at 9:55 PM, Sašo Kiselkov wrote: > Hi Lawrence, > > Why would you need to do an add_drv after reflashing? These cards should > work out of the box with oi151a7. > > -- > Saso > > On 02/25/2013 02:48 PM, Lawrence wrote: >> Hi All, >> >> I have a IBM ServeRAID M1015 RAID controller which I tried to cross-flash to >> LSA 9211-8i IT mode as mentioned in this website: >> http://www.servethehome.com/ibm-serveraid-m1015-part-4/. >> >> I have a IBM x3650 M3 server which I then use with the ServeRAID M1015 raid >> card to test if my card is working in the IT mode as mentioned. I have tried >> booting using OpenIndiana 151a and 151a7 LiveCD/USB to try and detect the >> card. The system is able to detect the raid card but when I tried to add the >> drivers "mpt_sas" to the system, I got the following errors: >> >> root@openindiana:~# add_drv -i >> "pci1014,3b1" mpt_sas >> devfsadm: driver failed to attach: >> mpt_sas >> Warning: Driver (mpt_sas) successfully >> added to system but failed to attach >> >> Feb 21 17:14:22 openindiana scsi: [ID >> 107833 kern.warning] WARNING: >> /pci@0,0/pci8086,3410@9/pci1014,3b1@0 >> (mpt_sas0): >> Feb 21 17:14:22 openindiana hard reset >> failed! >> Feb 21 17:14:22 openindiana scsi: [ID >> 107833 kern.warning] WARNING: >> /pci@0,0/pci8086,3410@9/pci1014,3b1@0 >> (mpt_sas0): >> Feb 21 17:14:22 openindiana mptsas >> chip initialization failed >> Feb 21 17:14:22 openindiana scsi: [ID >> 107833 kern.warning] WARNING: >> /pci@0,0/pci8086,3410@9/pci1014,3b1@0 >> (mpt_sas0): >> Feb 21 17:14:22 openindiana attach >> failed >> >> Boot to the RAID controller, I gathered the following information: >> Firmware Version: 2.70.74-1038 >> FW Package Version: 20.5.1-0014 >> FW Time: Oct 13 2010, 13:52:10 >> WebBIOS Version: 4.0-e_24-Rel >> SubVendor ID: 0x1014 >> SubDevice ID: 0x3b1 >> >> Doing a scanpci: >> sudo scanpci | less #search for LSI >> pci bus 0x0010 cardnum 0x00 function 0x00: vendor 0x1000 device >>0x0073 >> LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] >> === >> >> So it does find the card. And then prtconf: >> = >> jack@openindiana:~$ prtconf -Dv | less #search for 73 >>pci1014,3b1 (driver name: mpt_sas) >>Hardware properties: >>name='pci-msix-capid-pointer' type=int items=1 >>value=00c0 >>name='pci-msi-capid-pointer' type=int items=1 >>value=00a8 >>name='assigned-addresses' type=int items=15 >> >> value=81100010..1000..0100.83100014..9294..4000.8310001c.000 >> 0.9290..0004 >>name='reg' type=int items=20 >> >> value=0010.....01100010....0100.03100014.000 >> 0...4000.0310001c....0004 >>name='compatible' type=string items=13 >>value='pciex1000,73.1014.3b1.3' + >>'pciex1000,73.1014.3b1' + 'pciex1000,73.3' + 'pciex1000,73' + >>'pciexclass,010400' + 'pciexclass,0104' + 'pci1000,73.1014.3b1.3' + >>'pci1000,73.1014.3b1' + 'pci1014,3b1' + 'pci1000,73.3' + >>'pci1000,73' + 'pciclass,010400' + 'pciclass,0104' >>name='model' type=string items=1 >>value='RAID controller' >>name='power-consumption' type=int items=2 >>value=0001.0001 >>name='devsel-speed' type=int items=1 >>value= >>name='interrupts' type=int items=1 >>value=0001 >>name='subsystem-vendor-id' type=int items=1 >>value=1014 >>name='subsystem-id' type=int items=1 >>value=03b1 >>name='unit-address' type=string items=1 >>value='0' >>name='class-code' type=int items=1 >>value=00010400 >>name='revision-id' type=int items=1 >>val
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
On 2013-02-25 16:02, Jonathan Adams wrote: actually, probably the issue is more with the fact that the package went into maintenance, it would probably be better to go offline if the configuration files wasn't there ... however it trying to run allowed the script to output that the config files didn't exist ... so maybe it _is_ best leaving it the way it is. For moderately integrated packages - i.e. used almost "as is" from an upstream repo which has little idea about SMF - this is likely a good approach. At least, it works to forbid running unconfigured services and attracts administrative attention. Possibly, some more awareness is needed for admins that just began working with this OS about how to recover from such errors and where to look for hints (SMF logs and all). For example, a "restart" of a service in the "maintenance" state could at least complain that it's not gonna really restart the service (alternately see RFE #3596). However, IF the set of required config files is known, they can and should be listed as dependencies of the SMF instance (or reverse deps if some block-files are used to require an admin to revise configs and remove the block-file when he's done). I don't quite agree that in general, an enabled service which can't work should be made "offline". There are cases when it might be a proper thing to do, but in general "maintenance" is just for that, whatever the reason of a failure. I am however annoyed by some services that fail remote dep checks in their method scripts (i.e. can't contact a database server) and fail quickly several times in a row - and are thus put into the "maintenance" state. This often mis-happens during poweron of some larger distributed systems, when clients happen to start before a DBMS or LDAP server completes its integrity checks. But this is at least a known case, and we have scripts to work around that in some cases, or try to configure SMF's tolerance to quick restarts (or induce delays into start-scripts) in others... I've long thought about how cool it would be to have a simple means to check remote systems' SMF states and define dependencies onto those (including "suffices to have one of that replicated service's instances running")... What is other list members' mileage? ;) //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SMF "svcadm restart-or-clear-or-start" action
FWIW, I added this RFE to illumos bugtracker so it can be found by people looking to do simple useful quests and develop illumos: https://www.illumos.org/issues/3596 On 2013-02-12 00:12, Jim Klimov wrote: Hello all, While setting up systems there are occasions when an SMF service needs to be restarted - i.e. due to reconfiguration or its failure. The "svcadm restart" action only takes place for "online" services. I wonder if it is a reasonable RFE to add some command (and what should it be called?) to try to "kick" a service into "online" state from whatever starting situation. For an already "online" service this would act as a "restart", for an "offline" service this would be an "enable", and a service in "maintenance" this would "clear". This should likely do nothing with services in transitional state (currently becoming online or offline - though maybe request restart of the latter), and of course the action may fail again (likely into maintenance) if the service is still misconfigured. It is just annoying to have to verify the service's current state before "kicking" it, though I've spawned a simple admin-script on my systems to do this chore ;) I think the solution should be a part of the common SMF structure. And it is a bite-size task for any enthusiast, now that we have a few :) //Jim Klimov ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
actually, probably the issue is more with the fact that the package went into maintenance, it would probably be better to go offline if the configuration files wasn't there ... however it trying to run allowed the script to output that the config files didn't exist ... so maybe it _is_ best leaving it the way it is. On 25 February 2013 14:50, Jim Klimov wrote: > On 2013-02-25 14:54, Dmitry Kozhinov wrote: >> >> I am not accusing anyone, but just trying to understand: >> Why not make a package so that it would run out-of-the-box? >> >> When you buy a car, imagine that engine would not start unless you: >> - Kick right rear tire; >> - Open and close trunk lid; >> - You name what else... >> >> Maybe those who know what-to-do (to simply get a package running) feel >> themselves gurus, which is cool, but obviously making things go this way >> condemns the great OS into extinction. > > > > The steps you've described are more akin to the need to pick correct > dependencies and rule out possible conflicts of several implementations, > as also happens to be needed - and indeed, such packages should be > fixed. > > There are many other packages which can work "as is" either because > they need no custom configuration (i.e. an office suite), or because > they can use some system configs (default domain name, UNIX user ids) > and thus not require customization - although that is often needed > down the road. For example, a web browser might need proxy settings > if it doesn't consult http_proxy envvars, or trust to your corporate > CA root, and those settings are too custom to distribute in a common > repository (though in a corporate setting you might like to maintain > your own repo with common settings baked into packages). > > And there are programs which require configuration. You can't go around > that - an LDAP server or a database needs to know its root suffix name > and unique administrative login credentials, its clients - also. Even > getting to work something as simple as an NTP client might require that > you provide your preferred NTP servers (i.e. ones in your LAN, or from > your nearby ISP); relaying from sendmails through a common single relay > requires you to set the DS option (aka smarthost), etc. > > What *could* be done better in such cases is provision of SMF manifests > to integrate the services, including dependencies on config files - so > that if the service fails to start, "svcs -xv" can better show you why. > And also I've just recently raised an RFE to have a common svcadm option > to enable/restart/clear an SMF service instance in one command and not > caring about the service's previous state. > > There are many examples of programs which include separate steps of > installation (which provides files onto a filesystem) and configuration > (which customizes the setup and enables services). Often the config > programs can implement a "silent" mode, so that they don't ask questions > interactively but rather read prepared answer-files (usually made by > saving another config session's results into a special format). > > Remember that the packaging paradigm, especially with IPS, considers the > delivery of packaged software into non-executing OS images (i.e. into an > inactive local zone), and any configuration would run only in this zone > context when it boots. This is assumed more reliable than the preinstall > and postinstall scripts in SVR4 which were written before local zones > were invented and never changed since then. Some packages now use some > hackery like SMF services which do the same tasks to configure the > custom installation and self-destruct or hide. I am not sure how well > this works along with de-configuration and removal of packages (i.e. > preremove/postremove in SVR4 terms) and how upgrades are differentiated. > > HTH, > //Jim > > PS: At least, in many cases we are beyond DIY car sales, where you get > boxes of components, a purse of tools and documentation - and build > your car just like you would assemble an IKEA bed. Though, this is not > yet always the case in IT (nor is it generally possible for each and > any package). > > Being, apparently, from Russia you should know that this is not very > much a joke - a reform of the car industry did once suggest such > distribution of cars: factories don't do a very high quality job > anyway, so people often have to take new cars apart and rebuild them. > Distributing boxes of pieces would save everyone time and money ;) > > //Jim > > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
On 2013-02-25 14:54, Dmitry Kozhinov wrote: I am not accusing anyone, but just trying to understand: Why not make a package so that it would run out-of-the-box? When you buy a car, imagine that engine would not start unless you: - Kick right rear tire; - Open and close trunk lid; - You name what else... Maybe those who know what-to-do (to simply get a package running) feel themselves gurus, which is cool, but obviously making things go this way condemns the great OS into extinction. The steps you've described are more akin to the need to pick correct dependencies and rule out possible conflicts of several implementations, as also happens to be needed - and indeed, such packages should be fixed. There are many other packages which can work "as is" either because they need no custom configuration (i.e. an office suite), or because they can use some system configs (default domain name, UNIX user ids) and thus not require customization - although that is often needed down the road. For example, a web browser might need proxy settings if it doesn't consult http_proxy envvars, or trust to your corporate CA root, and those settings are too custom to distribute in a common repository (though in a corporate setting you might like to maintain your own repo with common settings baked into packages). And there are programs which require configuration. You can't go around that - an LDAP server or a database needs to know its root suffix name and unique administrative login credentials, its clients - also. Even getting to work something as simple as an NTP client might require that you provide your preferred NTP servers (i.e. ones in your LAN, or from your nearby ISP); relaying from sendmails through a common single relay requires you to set the DS option (aka smarthost), etc. What *could* be done better in such cases is provision of SMF manifests to integrate the services, including dependencies on config files - so that if the service fails to start, "svcs -xv" can better show you why. And also I've just recently raised an RFE to have a common svcadm option to enable/restart/clear an SMF service instance in one command and not caring about the service's previous state. There are many examples of programs which include separate steps of installation (which provides files onto a filesystem) and configuration (which customizes the setup and enables services). Often the config programs can implement a "silent" mode, so that they don't ask questions interactively but rather read prepared answer-files (usually made by saving another config session's results into a special format). Remember that the packaging paradigm, especially with IPS, considers the delivery of packaged software into non-executing OS images (i.e. into an inactive local zone), and any configuration would run only in this zone context when it boots. This is assumed more reliable than the preinstall and postinstall scripts in SVR4 which were written before local zones were invented and never changed since then. Some packages now use some hackery like SMF services which do the same tasks to configure the custom installation and self-destruct or hide. I am not sure how well this works along with de-configuration and removal of packages (i.e. preremove/postremove in SVR4 terms) and how upgrades are differentiated. HTH, //Jim PS: At least, in many cases we are beyond DIY car sales, where you get boxes of components, a purse of tools and documentation - and build your car just like you would assemble an IKEA bed. Though, this is not yet always the case in IT (nor is it generally possible for each and any package). Being, apparently, from Russia you should know that this is not very much a joke - a reform of the car industry did once suggest such distribution of cars: factories don't do a very high quality job anyway, so people often have to take new cars apart and rebuild them. Distributing boxes of pieces would save everyone time and money ;) //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
I generally agree with your attitude: for dovecot that is a TALL order, and my Windows experience so far is that similar mishaps occur in that universe, too. Down the dovecot road there might be some sort of future setup tool, that asks the installing user what she intends to use dovecot for and produces some sort of boilerplate conf tree, and asks about what certs to use and whetever else seems obvious and asks the user to select one config type out of a few. . Today there isn't. On 2013-02-25 14:54, Dmitry Kozhinov wrote: I am not accusing anyone, but just trying to understand: Why not make a package so that it would run out-of-the-box? When you buy a car, imagine that engine would not start unless you: - Kick right rear tire; - Open and close trunk lid; - You name what else... Maybe those who know what-to-do (to simply get a package running) feel themselves gurus, which is cool, but obviously making things go this way condemns the great OS into extinction. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Unable to load RAID driver
Hi Lawrence, Why would you need to do an add_drv after reflashing? These cards should work out of the box with oi151a7. -- Saso On 02/25/2013 02:48 PM, Lawrence wrote: > Hi All, > > I have a IBM ServeRAID M1015 RAID controller which I tried to cross-flash to > LSA 9211-8i IT mode as mentioned in this website: > http://www.servethehome.com/ibm-serveraid-m1015-part-4/. > > I have a IBM x3650 M3 server which I then use with the ServeRAID M1015 raid > card to test if my card is working in the IT mode as mentioned. I have tried > booting using OpenIndiana 151a and 151a7 LiveCD/USB to try and detect the > card. The system is able to detect the raid card but when I tried to add the > drivers "mpt_sas" to the system, I got the following errors: > > root@openindiana:~# add_drv -i > "pci1014,3b1" mpt_sas > devfsadm: driver failed to attach: > mpt_sas > Warning: Driver (mpt_sas) successfully > added to system but failed to attach > > Feb 21 17:14:22 openindiana scsi: [ID > 107833 kern.warning] WARNING: > /pci@0,0/pci8086,3410@9/pci1014,3b1@0 > (mpt_sas0): > Feb 21 17:14:22 openindiana hard reset > failed! > Feb 21 17:14:22 openindiana scsi: [ID > 107833 kern.warning] WARNING: > /pci@0,0/pci8086,3410@9/pci1014,3b1@0 > (mpt_sas0): > Feb 21 17:14:22 openindiana mptsas > chip initialization failed > Feb 21 17:14:22 openindiana scsi: [ID > 107833 kern.warning] WARNING: > /pci@0,0/pci8086,3410@9/pci1014,3b1@0 > (mpt_sas0): > Feb 21 17:14:22 openindiana attach > failed > > Boot to the RAID controller, I gathered the following information: > Firmware Version: 2.70.74-1038 > FW Package Version: 20.5.1-0014 > FW Time: Oct 13 2010, 13:52:10 > WebBIOS Version: 4.0-e_24-Rel > SubVendor ID: 0x1014 > SubDevice ID: 0x3b1 > > Doing a scanpci: > sudo scanpci | less #search for LSI > pci bus 0x0010 cardnum 0x00 function 0x00: vendor 0x1000 device > 0x0073 > LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] > === > > So it does find the card. And then prtconf: > = > jack@openindiana:~$ prtconf -Dv | less #search for 73 > pci1014,3b1 (driver name: mpt_sas) > Hardware properties: > name='pci-msix-capid-pointer' type=int items=1 > value=00c0 > name='pci-msi-capid-pointer' type=int items=1 > value=00a8 > name='assigned-addresses' type=int items=15 > > value=81100010..1000..0100.83100014..9294..4000.8310001c.000 > 0.9290..0004 > name='reg' type=int items=20 > > value=0010.....01100010....0100.03100014.000 > 0...4000.0310001c....0004 > name='compatible' type=string items=13 > value='pciex1000,73.1014.3b1.3' + > 'pciex1000,73.1014.3b1' + 'pciex1000,73.3' + 'pciex1000,73' + > 'pciexclass,010400' + 'pciexclass,0104' + 'pci1000,73.1014.3b1.3' + > 'pci1000,73.1014.3b1' + 'pci1014,3b1' + 'pci1000,73.3' + > 'pci1000,73' + 'pciclass,010400' + 'pciclass,0104' > name='model' type=string items=1 > value='RAID controller' > name='power-consumption' type=int items=2 > value=0001.0001 > name='devsel-speed' type=int items=1 > value= > name='interrupts' type=int items=1 > value=0001 > name='subsystem-vendor-id' type=int items=1 > value=1014 > name='subsystem-id' type=int items=1 > value=03b1 > name='unit-address' type=string items=1 > value='0' > name='class-code' type=int items=1 > value=00010400 > name='revision-id' type=int items=1 > value=0003 > name='vendor-id' type=int items=1 > value=1000 > name='device-id' type=int items=1 > value=0073 > > === > > With the OI 151a7 liveUSB, I noticed that in the Device D
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
I am not accusing anyone, but just trying to understand: Why not make a package so that it would run out-of-the-box? When you buy a car, imagine that engine would not start unless you: - Kick right rear tire; - Open and close trunk lid; - You name what else... Maybe those who know what-to-do (to simply get a package running) feel themselves gurus, which is cool, but obviously making things go this way condemns the great OS into extinction. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Unable to load RAID driver
Hi All, I have a IBM ServeRAID M1015 RAID controller which I tried to cross-flash to LSA 9211-8i IT mode as mentioned in this website: http://www.servethehome.com/ibm-serveraid-m1015-part-4/. I have a IBM x3650 M3 server which I then use with the ServeRAID M1015 raid card to test if my card is working in the IT mode as mentioned. I have tried booting using OpenIndiana 151a and 151a7 LiveCD/USB to try and detect the card. The system is able to detect the raid card but when I tried to add the drivers "mpt_sas" to the system, I got the following errors: root@openindiana:~# add_drv -i "pci1014,3b1" mpt_sas devfsadm: driver failed to attach: mpt_sas Warning: Driver (mpt_sas) successfully added to system but failed to attach Feb 21 17:14:22 openindiana scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci8086,3410@9/pci1014,3b1@0 (mpt_sas0): Feb 21 17:14:22 openindiana hard reset failed! Feb 21 17:14:22 openindiana scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci8086,3410@9/pci1014,3b1@0 (mpt_sas0): Feb 21 17:14:22 openindiana mptsas chip initialization failed Feb 21 17:14:22 openindiana scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci8086,3410@9/pci1014,3b1@0 (mpt_sas0): Feb 21 17:14:22 openindiana attach failed Boot to the RAID controller, I gathered the following information: Firmware Version: 2.70.74-1038 FW Package Version: 20.5.1-0014 FW Time: Oct 13 2010, 13:52:10 WebBIOS Version: 4.0-e_24-Rel SubVendor ID: 0x1014 SubDevice ID: 0x3b1 Doing a scanpci: sudo scanpci | less #search for LSI pci bus 0x0010 cardnum 0x00 function 0x00: vendor 0x1000 device 0x0073 LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] === So it does find the card. And then prtconf: = jack@openindiana:~$ prtconf -Dv | less #search for 73 pci1014,3b1 (driver name: mpt_sas) Hardware properties: name='pci-msix-capid-pointer' type=int items=1 value=00c0 name='pci-msi-capid-pointer' type=int items=1 value=00a8 name='assigned-addresses' type=int items=15 value=81100010..1000..0100.83100014..9294..4000.8310001c.000 0.9290..0004 name='reg' type=int items=20 value=0010.....01100010....0100.03100014.000 0...4000.0310001c....0004 name='compatible' type=string items=13 value='pciex1000,73.1014.3b1.3' + 'pciex1000,73.1014.3b1' + 'pciex1000,73.3' + 'pciex1000,73' + 'pciexclass,010400' + 'pciexclass,0104' + 'pci1000,73.1014.3b1.3' + 'pci1000,73.1014.3b1' + 'pci1014,3b1' + 'pci1000,73.3' + 'pci1000,73' + 'pciclass,010400' + 'pciclass,0104' name='model' type=string items=1 value='RAID controller' name='power-consumption' type=int items=2 value=0001.0001 name='devsel-speed' type=int items=1 value= name='interrupts' type=int items=1 value=0001 name='subsystem-vendor-id' type=int items=1 value=1014 name='subsystem-id' type=int items=1 value=03b1 name='unit-address' type=string items=1 value='0' name='class-code' type=int items=1 value=00010400 name='revision-id' type=int items=1 value=0003 name='vendor-id' type=int items=1 value=1000 name='device-id' type=int items=1 value=0073 === With the OI 151a7 liveUSB, I noticed that in the Device Driver Utility, the system is saying the RAID card is misconfigured. I have tried using an Ubuntu LiveCD and it can see the card and is able to detect the harddisks that is attached to the card. Does anyone have any similiar experience? Is there any other drivers or setting that I need to configure? Best Regards. ___ OpenIn
[OpenIndiana-discuss] idmap timeout
Hi all, Another idmap issue! Just trying a new VM for some troubleshooting and I can't seem to get the name_cache_timeout and id_cache_timeout settings to work on here. I've run: svccfg -s svc:/system/idmap setprop config/name_cache_timeout=count: 31536000 svccfg -s svc:/system/idmap setprop config/id_cache_timeout=count: 31536000 but I'm still seeing UIDs changing every 10 minutes (cron job here running an id to a file every minute): 13:05:00 uid=2147491845 gid=2147483650(Domain Users@themacplace.private) 13:06:00 uid=2147491845 gid=2147483650(Domain Users@themacplace.private) 13:07:00 uid=2147491845 gid=2147483650(Domain Users@themacplace.private) 13:08:00 uid=2147491845 gid=2147483650(Domain Users@themacplace.private) 13:09:00 uid=2147491845 gid=2147483650(Domain Users@themacplace.private) 13:10:00 uid=2147491845 gid=2147483650(Domain Users@themacplace.private) 13:11:00 uid=2147491846(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) 13:12:00 uid=2147491846(james@themacplace.private) gid=2147483650(Domain Users@themacplace.private) 13:13:00 uid=2147491846 gid=2147483650(Domain Users@themacplace.private) 13:14:00 uid=2147491846 gid=2147483650(Domain Users@themacplace.private) 13:15:00 uid=2147491846 gid=2147483650(Domain Users@themacplace.private) 13:16:00 uid=2147491846 gid=2147483650(Domain Users@themacplace.private) 13:17:00 uid=2147491846 gid=2147483650(Domain Users@themacplace.private) Does anyone know if this is a bug, or expected behaviour? Obviously doesn't affect CIFS at all, but I'm trying to do some troubleshooting against another service. What also seems a bit weird is the output format of id changes when the id ticks over (adds the username into brackets)? Thanks, James. Website:www.themacplace.co.uk ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
Thanks to advices from Rob McMahon: svcs -l dovecot Showed where the log file is, and log file indicated that /etc/dovecot/dovecot.conf was initially missing; svcadm clear dovecot Resolved the issue when the dovecot.conf was in place. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
you needed to try a "svcadm clear dovecot" ... it was still in maintenance from the first time it was enabled. Jon On 25 February 2013 12:34, Dmitry Kozhinov wrote: > Thank you for the replies. I need Dovecot only to provide an authentication > mechanism for Postfix. So all that I wanted to do: > - Install Dovecot; > - Run Dovecot service; > - Tweak Dovecot configuration so that Postfix can use authentication. > > I have run GUI Package Manager (I am a newcomer from Windows world, > sorry...) and have searched for "dovecot". Strangely Webmin appeared in the > search results, obviously not what I need. So I added SFE repository and > searched again. The search revealed three packages: > - "dovecot/src" version: 2.1.14 > - "imap/dovecot" version: 2.1.14 > - "network/dovecot" version: 2.0.13 > > Note that all three packages indicate "Category: None", so that it is > impossible to find them using Category tree at left side of Package Manager. > > I have installed the "imap/dovecot" package. Then (the # denotes command > prompt here): > > # svcs dovecot > STATE STIMEFMRI > disabled 17:54:49 svc:/site/dovecot:default > > Aha, disabled. Trying to enable: > > # svcadm enable dovecot > svcs dovecot > STATE STIMEFMRI > maintenance17:57:36 svc:/site/dovecot:default > > Maintenance... Isn't it should run out-of-the box? Trying to apply your > advices: > > # pfexec mkdir -p /etc/ssl/certs > # pfexec mkdir /etc/ssl/private > # cd /usr/share/doc/dovecot/example-config > # pfexec cp -p -R conf.d/ dovecot.conf /etc/dovecot/ > # cd /usr/share/doc/dovecot > # pfexec sh mkcert.sh > # svcadm enable dovecot > > And is it running? > > # svcs dovecot > STATE STIMEFMRI > maintenance17:57:36 svc:/site/dovecot:default > > Maintenance... Maybe another package "network/dovecot" is missing? Trying to > install with GUI Package Manager, and it says "No updates necessary", and > indicates that "network/dovecot" is not installed. > > So I ended installing Dovecot from OpenCSW, which went trouble-free. Up and > running now. > > - Dmitry. > > > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Status OpenIndiana CI
Dear all, following my previous mail I started looking for continuous integration possibilities and to my surprise (or not) found reference to Jenkins build server that was active at least at some point: http://wiki.openindiana.org/oi/Building+with+oi-build references ci-master.uk.openindiana.org. Where has that gone? Is it only temporarily down? Cheers Stefan Acando GmbH, Millerntorplatz 1, 20359 Hamburg, Germany | Geschäftsführer: Guido Ahle | Amtsgericht Hamburg, HRB 76048 | Ust.Ident-Nr.:DE208833022 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
Thank you for the replies. I need Dovecot only to provide an authentication mechanism for Postfix. So all that I wanted to do: - Install Dovecot; - Run Dovecot service; - Tweak Dovecot configuration so that Postfix can use authentication. I have run GUI Package Manager (I am a newcomer from Windows world, sorry...) and have searched for "dovecot". Strangely Webmin appeared in the search results, obviously not what I need. So I added SFE repository and searched again. The search revealed three packages: - "dovecot/src" version: 2.1.14 - "imap/dovecot" version: 2.1.14 - "network/dovecot" version: 2.0.13 Note that all three packages indicate "Category: None", so that it is impossible to find them using Category tree at left side of Package Manager. I have installed the "imap/dovecot" package. Then (the # denotes command prompt here): # svcs dovecot STATE STIMEFMRI disabled 17:54:49 svc:/site/dovecot:default Aha, disabled. Trying to enable: # svcadm enable dovecot svcs dovecot STATE STIMEFMRI maintenance17:57:36 svc:/site/dovecot:default Maintenance... Isn't it should run out-of-the box? Trying to apply your advices: # pfexec mkdir -p /etc/ssl/certs # pfexec mkdir /etc/ssl/private # cd /usr/share/doc/dovecot/example-config # pfexec cp -p -R conf.d/ dovecot.conf /etc/dovecot/ # cd /usr/share/doc/dovecot # pfexec sh mkcert.sh # svcadm enable dovecot And is it running? # svcs dovecot STATE STIMEFMRI maintenance17:57:36 svc:/site/dovecot:default Maintenance... Maybe another package "network/dovecot" is missing? Trying to install with GUI Package Manager, and it says "No updates necessary", and indicates that "network/dovecot" is not installed. So I ended installing Dovecot from OpenCSW, which went trouble-free. Up and running now. - Dmitry. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
It's not OI specific ... if you read the Dovecot readme/look on the Dovecot website it tells you to go through these steps ... I have to go a couple of steps further (I still use Dovecot on Solaris 10, so I have to compile on that platform) where I have to include LDAP configuration, so for me OI's Dovecot worked out of the box too. Jon On 25 February 2013 08:51, Stefan Müller-Wilken wrote: > Dear all, > > I can second Hans mail. Dovecot is running like a charm here. And the > configuration steps Hans is writing about are part of any serious environment > specific configuration. Maybe one could add some sort of OI specific readme > to the package based on Hans' description. > > Cheers > Stefan > > > > Acando GmbH, Millerntorplatz 1, 20359 Hamburg, Germany | Geschäftsführer: > Guido Ahle | Amtsgericht Hamburg, HRB 76048 | Ust.Ident-Nr.:DE208833022 > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.
Dear all, I can second Hans mail. Dovecot is running like a charm here. And the configuration steps Hans is writing about are part of any serious environment specific configuration. Maybe one could add some sort of OI specific readme to the package based on Hans' description. Cheers Stefan Acando GmbH, Millerntorplatz 1, 20359 Hamburg, Germany | Geschäftsführer: Guido Ahle | Amtsgericht Hamburg, HRB 76048 | Ust.Ident-Nr.:DE208833022 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
