|
A tiny bit. The application input model is a lot better than XInput 2, but hardware support is still the same.
|
#
?
Aug 13, 2015 08:39
|
|
|
|
| # ? May 29, 2024 00:52 |
|
|
RFC2324 posted:If I add a disk without a partition to an LVM group, is it going to mess anything up? This should be fine, it's how I usually do it. It also helps you avoid rebooting, you used to be able to expand the partition on disk without rebooting but some assholes patched the kernel to block rescans of the partition table when some of the partitions are in use. (At least on redhat) Also if you add -r to your lvextend command it will automagically extend your XFS partition, fsck is done by XFS automatically at mount, the fsck.xfs command literally does nothing. theperminator fucked around with this message at 08:48 on Aug 13, 2015 |
|
#
?
Aug 13, 2015 08:42
|
|
|
What's the right way to route :80 traffic to :8080? I'm flooded with ways to do this, and unable to determine what the 'right' way is on CentOS w/ systemd. Seems like the way is to do it with iptables, right?
|
|
#
?
Aug 13, 2015 15:33
|
|
|
Barnyard Protein posted:What's the right way to route :80 traffic to :8080? I'm flooded with ways to do this, and unable to determine what the 'right' way is on CentOS w/ systemd. Seems like the way is to do it with iptables, right? I prefer doing it at the router, but if I had to do it at the system, I would use either iptables, or an htaccess redirect if its for web traffic.
|
|
#
?
Aug 13, 2015 15:38
|
|
|
probably best to manipulate iptables/firewalld with firewall-cmd
|
|
#
?
Aug 13, 2015 15:38
|
|
|
kujeger posted:probably best to manipulate iptables/firewalld with firewall-cmd if your distro uses that.
|
|
#
?
Aug 13, 2015 16:26
|
|
|
I don't like firewalld and I use the old iptable scripts instead 
|
|
#
?
Aug 13, 2015 16:32
|
|
|
RFC2324 posted:if your distro uses that. Barnyard Protein said centos w/ systemd, and that is centos 7 -- which uses firewalld
|
|
#
?
Aug 13, 2015 16:52
|
|
|
spankmeister posted:I don't like firewalld and I use the old iptable scripts instead The point of firewalld is that iptables is going away. You can learn nftables if you want to when the switch happens, but we're slowly trying to make it a little friendlier than "we deprecated $arcane_syntax so learn $new_arcane_syntax ASAP!"
|
|
#
?
Aug 13, 2015 18:01
|
|
|
No, don't take away my $arcane_syntax !!!!
|
|
#
?
Aug 13, 2015 18:02
|
|
|
RFC2324 posted:No, don't take away my $arcane_syntax !!!!  
|
|
#
?
Aug 13, 2015 18:04
|
|
|
I just got a Debian server provided by oneprovider and logging in for the first time there are two user accounts with directories in /home called "onepad67" and "ssadmin". What are they? 
|
|
#
?
Aug 13, 2015 18:48
|
|
|
Speaking of systemd, can anyone recommend a decent intro to it for us oldschool sysadmins who don't trust the newfangled whizbang? Where I work, we're staying on CentOS 6 for the foreseeable future specifically to avoid systemd. But I know I'm going to encounter it sooner or later, and when that happens, it'd be nice to at least have some clue what the hell I'm even looking at.
|
|
#
?
Aug 13, 2015 19:20
|
|
|
Powered Descent posted:Speaking of systemd, can anyone recommend a decent intro to it for us oldschool sysadmins who don't trust the newfangled whizbang?
|
|
#
?
Aug 13, 2015 19:29
|
|
|
Powered Descent posted:Where I work, we're staying on CentOS 6 for the foreseeable future specifically to avoid systemd. But I know I'm going to encounter it sooner or later, and when that happens, it'd be nice to at least have some clue what the hell I'm even looking at. systemd should be mostly invisible to you, except in the cases where it's way, way better than anything else. Like writing very dynamic, human-readable unit files for services in 20 lines, which properly trigger on a whole mess of dependency chains later, or filesystems being mounted, or whatever without 100-500 lines of horrible boilerplate shell that sources other awful shell utility scripts (or in the case of upstart, simply has bugs which will never be fixed), plus it can track forked children, etc What real reason do you have to avoid systemd other than "it's different", which applies to 500 other technologies you're not avoiding which are also different from their predecessors?
|
|
#
?
Aug 13, 2015 19:50
|
|
|
I'm having a terrible time sorting out some TLS w/ LDAP problems. Maybe someone can help me. I've been killing myself for a few days and it's driving me nuts. So I need to auth against LDAP from a Linux process. I don't need user login on the linux server itself, I just need my application to auth against ldap. I have all that working, just not with TLS, which is required for me to promote from dev to production. I'm having a CA Cert problem, and I'm just stumped. I know 100% what I'm doing, but it's just not working. 1) I went to the domain controller and download the CA Cert: http://dc1.company.com/certsrv Download CA Certificate in DER format 2) Uploaded it to the linux server and converted it to a PEM openssl x509 -inform der -in /service/ssl/certnew.cer -outform PEM -out /service/ssl/dc1.pem 3) Connect to LDAP Server on port 636 with openssl to test: openssl s_client -CAfile dc1.pem -connect dc1.em.corp:636 Usually this works, but I get an error (big CP) sorry. code:subject=/CN=DC1.me.corp issuer=/DC=corp/DC=me/CN=me-MECLOUD-SERV-CA Acceptable client certificate CA names /DC=corp/DC=me/CN=me-MECLOUD-SERV-CA Doesn't that mean the CA should match and be trusted? I can't figure it out. Is there a way to check the cert? Maybe our DC cert is invalid or something. Any help?
|
|
#
?
Aug 13, 2015 20:41
|
|
|
You could try supplying the server name to openssl in the event that the server requires SNI? openssl s_client -CAfile dc1.pem -connect dc1.em.corp:636 -servername dc1.em.corp
|
|
#
?
Aug 13, 2015 21:41
|
|
|
ChubbyThePhat posted:You could try supplying the server name to openssl in the event that the server requires SNI? Nope, doesn't work. I think from what I gathered via Googles, is that the LDAP server doesn't provide the entire certificate chain, so open_ssl doesn't trust it, even with the CA file.
|
|
#
?
Aug 13, 2015 21:45
|
|
|
ChubbyThePhat posted:You could try supplying the server name to openssl in the event that the server requires SNI? I don't think LDAP uses SNI at all.
|
|
#
?
Aug 13, 2015 21:52
|
|
|
spankmeister posted:I don't think LDAP uses SNI at all. Oh poo poo, you might be right.
|
|
#
?
Aug 13, 2015 21:54
|
|
|
evol262 posted:What real reason do you have to avoid systemd other than "it's different", which applies to 500 other technologies you're not avoiding which are also different from their predecessors? A few of the folks here do have that philosophical grudge against systemd, but the real reason we decided to stick with CentOS 6 for a while yet was because none of us really know what the hell we're doing, systemd-wise. There were no compelling reasons to make the leap that we could see, so we didn't.
|
|
#
?
Aug 13, 2015 23:25
|
|
|
SIR FAT JONY IVES posted:Nope, doesn't work. I think from what I gathered via Googles, is that the LDAP server doesn't provide the entire certificate chain, so open_ssl doesn't trust it, even with the CA file. Did you set TLS_CACERT? IIRC, this is required, but ldaps is hell. Powered Descent posted:A few of the folks here do have that philosophical grudge against systemd, but the real reason we decided to stick with CentOS 6 for a while yet was because none of us really know what the hell we're doing, systemd-wise. There were no compelling reasons to make the leap that we could see, so we didn't. From an administrator's perspective, it's identical to previous init systems, except where it's better. All the same commands you're used to still work (other than initctl, but you're probably not using that anyway). sysv init scripts still work with no changes if you have them, but you can probably scrap those and move to unit files. Everything boots faster, in parallel. It's an order of magnitude faster on most systems. There are really no downsides, and you don't need to know what you're doing, "systemd-wise", because all the tooling you're used to ("service foo start", "chkconfig foo on", etc) still works, though it may give deprecation warnings. You can mentally replace almost all of those with "systemctl start foo" or "systemctl enable foo" instead. That's it. There aren't really any valid philosophical objections to systemd. We've (I've) rehashed it repeatedly in this thread, but you should just tell whatever "folks" there who have a "philosophical objection" to it (presumably on the basis of Red Hat and Poettering being mustache twirling Linux villains) to read the Debian debates on init systems and why they settled on systemd. It's inarguably better than all its competitors in every way, and most of the complaints about systemd containing everything are actually about optional components under the systemd umbrella and not actually the init part. But if you want to learn way too much about systemd and all the ways in which it makes life as an admin better, you should go read this series
|
|
#
?
Aug 13, 2015 23:49
|
|
|
SIR FAT JONY IVES posted:
The domain controller certainly seems to be a CA. However, it might not be your root CA, but just an intermediate one. SIR FAT JONY IVES posted:
You've told OpenSSL to trust whatever certificate is in the dc1.pem file **for the purpose of validating other certificates only**. This means its validity for working as a server might still be undecided. And OpenSSL really wants to see the complete chain anyway. The "Certificate chain" indicates the certificate returned from dc1.em.corp port 636 had Subject /CN=dc1.me.corp, pretty much as expected. The issuer of that certificate was /DC=corp/DC=me/CN=me-MECLOUD-SERV-CA, and now OpenSSL wants to see a CA certificate that has exactly that as its Subject. SIR FAT JONY IVES posted:Is there a way to check the cert? Maybe our DC cert is invalid or something. Sure. Simple, but overly verbose: code:code:I am guessing your problem might be that the certificate in your dc1.pem has Subject: CN=dc1.me.corp. For the OpenSSL -CAfile option, you'll need a certificate that has Subject: DC=corp, DC=me, CN=me-MECLOUD-SERV-CA. If that's the top level certificate (i.e. its Subject and Issuer fields both have the exact same value), you're done. But if that certificate has a different Issuer, then you haven't reached the root of the chain yet and you'll have to get the certificate whose Subject is the same as the Issuer you just found. telcoM fucked around with this message at 06:01 on Aug 14, 2015 |
|
#
?
Aug 14, 2015 05:59
|
|
|
While we're all on the subject of certificates, is there a good walkthrough of how they work? I'm able to install them blindly following instructions but I'd like to know how things work under the hood so if something breaks I'm not endlessly searching in Google spinning my wheels.
|
|
#
?
Aug 14, 2015 15:18
|
|
|
There's a payload specifying various fields (e.g. who issued it? what website is it for?), specified in a standard called "X.509". You send that certificate to a certificate authority, who signs it. Your OS / browser has code and data to check for signatures for hundreds of different certificate authorities, and verifies that the signature is signed by one of those, and that the fields match up.
|
|
#
?
Aug 14, 2015 16:52
|
|
|
The whole "who issued it" thing can get tricky, because it's possible that "who issued it" wasn't a root CA, and the "issuer" field in "who issued it" also isn't a root CA, so you end up walking the chain back up, which is where Tony's issue potentially gets thorny.
|
|
#
?
Aug 14, 2015 17:37
|
|
|
Yeah, I think that's the problem. So the problem I have now is that I can get, at the client, LDAP with TLS working if I use a standalone ldap browser, and ldapsearch tools. In our software, though, TLS fails for user auth. I open a dev ticket, but until I reproduce it on a dev system here in house, they won't do anything. The problem with that, is this cert nonsense we are dealing with. They even sent me a cert and credentials on a test domain, but they fail too.
|
|
#
?
Aug 14, 2015 19:06
|
|
|
SIR FAT JONY IVES posted:Yeah, I think that's the problem. So the problem I have now is that I can get, at the client, LDAP with TLS working if I use a standalone ldap browser, and ldapsearch tools. In our software, though, TLS fails for user auth. I open a dev ticket, but until I reproduce it on a dev system here in house, they won't do anything. The problem with that, is this cert nonsense we are dealing with. Are you sure your failing executable uses with the systems native LDAP SDK? Beyond just having a different LDAP client library with a different SSL impl or trust store, more obscure problems I've seen in this neighborhood is servers that send their intermediate certificates out-of-order, which is tolerated by some SSL libraries and not others. If it's a total blackbox, In a pinch, I'd look at strace to see if any on-disk certificates or vaguely cert-related directories are loaded. If you can get a little bit of code slipped into your executable, have them try ldap_set_option of LDAP_DEBUG to produce some debugging to stderr. Values that are useful vary wildly (see e.g. http://httpd.apache.org/docs/trunk/mod/mod_ldap.html#ldaplibrarydebug). I don't recall seeing a verbatim error from your real app. On the off chance this happens to be some proprietary IBM software on Linux, name it and I can probable help as I have a lot of experience with their SSL and LDAP client libraries.
|
|
#
?
Aug 14, 2015 19:16
|
|
|
If it's the large financial I used to work for, they'll have 7 certificates in the signing chain, and the native ldapsearch stuff is the crap packed with VAS, but hopefully you're luckier.
|
|
#
?
Aug 14, 2015 20:06
|
|
|
covener posted:Are you sure your failing executable uses with the systems native LDAP SDK? It's a total black box, I'm just the SA that is installing it. What I have now is: 1) Client gave me a CA Cert, user, password, and dev LDAP server address. 2) From Java Explorer (an unrelated java app that I'm testing with) TLS, user, password, it all works 3) From our Management Console, which is a program we run that lets you configure our application, you can verify against LDAP, it works with TLS. 4) From our actual application, ldap auth works, but when you set "TLS=true" it always fails. The MC from #3 uses the same authentication, I though, so I'm not sure why that one fails. It's almost for sure a bug with or program. What sucks is that our docs don't specifically say where the CACert has to live. They mention how to confirm openldap, but don't give a reason why. For the MC you need to have the cert locally (like on your Windows PC) even though the Linux server does the actual auth. For the windows client I guess it's the same, but in the MC there's a field for Cert, no such field on the client side. In my applications log it says "LDAP ERROR:0" and that's it. So I opened up a ticket, but they told me I need to get it working locally before I sandbox on a client's LDAP system. My engineering manager helpfully pointed out we have an in-house test ldap domain, so I requested the cert, username, password, and address. I was given that, but the username and password fail. However, even if I had a working set of credentials, on the test server, I still get this: code:code:
|
|
#
?
Aug 14, 2015 20:43
|
|
|
evol262 posted:If it's the large financial I used to work for, they'll have 7 certificates in the signing chain, and the native ldapsearch stuff is the crap packed with VAS, but hopefully you're luckier. The issue is not at the bank, it's with the test dc my company has. They won't help me troubleshoot it at the bank, I have to duplicate it here, which means figuring out the cert from this system. At the bank it all works fine, except for in our app, so I know the cert is good there. I have to solve a problem that I'm not having at the client here first, then I can get help from my developers. It's irritating.
|
|
#
?
Aug 14, 2015 20:44
|
|
|
I think I finally get it:code:However, the server I'm connecting to gives me the same thing: code:How can I get that cert? I have no idea. usually I'd just go to http://dc1.emtest.corp/certsrv and grab it, but gives me the same one I have here.
|
|
#
?
Aug 14, 2015 21:16
|
|
|
SIR FAT JONY IVES posted:
It's telling you: "I got a certificate with Subject 'CN=dc1test.emtest.corp' and Issuer 'DC=corp, DC=EMTEST, CN=EMTEST'. To validate this, I would need a certificate one higher up in the chain: one with Subject 'DC=corp, DC=EMTEST, CN=EMTEST'. But I don't have such a certificate." This is how the trust chain is built up: 1.) there is a self-signed root CA certificate: it has subject X and issuer X. 2.) the root certificate is used to sign the certificate(s) of intermediate CA(s). They will have subject Y and issuer X. 3.) whatever is signed by the intermediate CA(s) will have subject Z (= whatever they are certifying) and issuer Y. There may be zero, one or many levels of intermediate CAs between the root CA and the actual server certificate you are trying to validate. SIR FAT JONY IVES posted:
Also, that's a bit shortish key (only 1024 bits) with a weakish cipher (RC4-MD5). But this does not seem to be an actual problem, at least not yet. Newer OpenSSL versions may have stricter requirements, but these requirements are usually adjustable. SIR FAT JONY IVES posted:viewing the CA Cert they provided I get this: That's just a copy of the certificate of the host you're talking to. Subject = "who I am" Issuer = "who vouches for me" You have the first, but you'll need the second. OpenSSL needs to see the certificate of the issuer in order to verify that the CA signature in this certificate is valid. Fortunately, the certificate itself tells you where you can (hopefully) get the issuer's certificate: SIR FAT JONY IVES posted:
This gives you both LDAP and HTTP URLs where the issuer certificate is supposed to be available. Try: code:If you want/have to use the CAfile option of OpenSSL, just add all the required CA certificates in a single file in PEM format.
|
|
#
?
Aug 14, 2015 21:32
|
|
|
Suspicious Dish posted:There's a payload specifying various fields (e.g. who issued it? what website is it for?), specified in a standard called "X.509". You send that certificate to a certificate authority, who signs it. Your OS / browser has code and data to check for signatures for hundreds of different certificate authorities, and verifies that the signature is signed by one of those, and that the fields match up. A minor point of clarification: You send a certificate signing request (CSR) to a certificate authority (CA). The CA verifies and signs the CSR and issues a certificate. In case anyone is interested, here is a brief overview of X.509 certificate generation and X.509 certificate verification:
When an application (for example, a web browser) initiates a TLS connection, the following happens:
A trusted certificate store is a list of trusted certificates. The list of trusted certificate store varies by operating system and application. Under Windows, for example, Chrome and Internet Explorer use the Windows trusted certificate store, while Firefox uses its own. Each application and/or operating system vendor has a set of policies that a CA must comply with in order for the CA's certificates to be included in the vendor's trusted certificate store (here is Mozilla's, and here is Microsoft's). (Note: Lots of details omitted for brevity).
|
|
#
?
Aug 14, 2015 22:16
|
|
|
SIR FAT JONY IVES posted:I think I finally get it: I wouldn't call that CA, it's going to lead to a lot of confusion. CA implies a root, self-signed issuer.
|
|
#
?
Aug 14, 2015 23:13
|
|
|
telcoM posted:Also, that's a bit shortish key (only 1024 bits) with a weakish cipher (RC4-MD5). But this does not seem to be an actual problem, at least not yet. Newer OpenSSL versions may have stricter requirements, but these requirements are usually adjustable. Not just "ish" but plain insecure. You will fail any kind of audit using that.
|
|
#
?
Aug 15, 2015 05:09
|
|
|
spankmeister posted:Not just "ish" but plain insecure. You will fail any kind of audit using that. The test domain is just an in-house system designed for that purpose, at the bank, it's considerably more secure, but I didn't copy and paste that cert for overly caution reasons. Thanks to all the guys that helped out. I see the issue, but since I don't have any admin access to the domain, I opened an internal ticket to get the info I need. I assume they will not be able to help me, but that's that. telcoM posted:
The wget did not work. I suppose I can just cat all the files together into a log file, as long as each segment begins and ends with ---BEGIN/END--- right?
|
|
#
?
Aug 15, 2015 19:24
|
|
|
Bit of a niche question: does anyone have a link to Ubuntu Lightscribe drivers/software. Seem to be a lot of dead links around: does no-one use it anymore?
|
|
#
?
Aug 17, 2015 11:22
|
|
|
The whole thing seems pretty deprecated. There are no offical drivers for any system and I don't think there are any recent linux third party tools.
|
|
#
?
Aug 17, 2015 14:36
|
|
|
|
| # ? May 29, 2024 00:52 |
|
|
Update on the LDAP thing: I ended up grabbing the cert from here: http://dc1test.emtest.corp/CertEnroll/DC1TEST.EMTEST.corp_EMTEST.crt That worked, the problem was that the EMTEST was serving the wrong cert, so our ldap guys fixed that. Once they did, all the TLS ldap starting working. Relating to our software, turns out there's two different ways to configure ldap with TLS, one way lets you just browse it as an admin to add users, another way to specifically define a CA Cert for user login. Of course they weren't both documented.
|
|
#
?
Aug 18, 2015 16:10
|
|