[Philipp Kern] > I still have to align with Russ' reasoning. The SRV handling looks > totally wrong. To do it this way just to accommodate a certain > broken site does not look like technical excellence to me. Sorry.
Well, the options at this time is to (1) release sssd without any automatic configuration (version 1.2.1-1), ensuring it require manual configuration at all sites or (2) updating the version in testing with the version in unstable (version 1.2.1-3) which will work for Debian Edu and site I am working (uio.no) while leaving other sites to still require other sites to do manual configuration. The algorithm I implemented will work for sites only providing SRV entries as well as those like uio.no where service specific DNS aliases are used for unix clients but not windows clients, instead of only working for sites where the SRV entries are used for the unix clients. The alternative algorithm proposed by Ross will fail for sites using SRV records for windows clients and DNS aliases for unix clients, and this seem like a bad idea to me. The implemented algorithm seem to work for mit.edu too (just test using /usr/lib/sssd/generate-config mit.edu), but I do can only look at the values and they seem to make sense to me. I do not really know if those settings really are the correct ones without a mit.edu account. :) Finding an algorithm that will work for more sites would be great, but seem unlikely at this time in the release cycle, and thus I believe it is not really an option. Implementing a algorithm that fail for the only sites I know is not really an option for me. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100817123442.ge13...@login2.uio.no
