Go download Jad and install it. Then unzip your jar file:
unzip sourcefile.jar
This command will decompile all the .class files in source_dir and put the new files in target_dir with a .java file extension on them.
jad -o -r -sjava -dtarget_dir ‘source_dir/**/*.class’
Was having some trouble with a few users not able to access their home directories on a Samba server.
/var/log/samba/log.smbd showed:
[2008/07/29 09:36:52, 2] auth/auth.c:check_ntlm_password(319) check_ntlm_password: Authentication for user [username] -> [username] FAILED with error NT_STATUS_NO_SUCH_USER
[2008/07/29 09:36:52, 0] smbd/service.c:make_connection(1191) hostname (10.10.10.10) couldn’t find service username
Testing:
- Their Active Directory account was good.
- On file server, kinit username worked.
- On file server, wbinfo -u returned that user.
- On file server, net user returned that user.
- On file server, wbinfo -i username returned “Could not get info for user username“.
The problem ended up being a corrupted /var/cache/samba/winbindd_idmap.tdb. Moved the file, restarted samba, and after a couple of minutes, everyone was back. The only problem was that that file contained the map of username to UID. When it recreated, nothing matched up. So I had to change ownership of everyone’s stuff. Easy enough to do with perl:
my @dirs = <*>;
for my $dir (@dirs) {
next if $dir =~ /_/;
system("chown -R \"$dir\:Domain Users\" $dir");
}
This is annoying and it has happened to me twice now, so it’s worth telling how I fixed it.
I use the search bar in Firefox pretty extensively, so you can imagine my surprise when the Google disappeared from it. I still don’t know how it happened, but I landed on this article, the gist of which is if you use version 2 or higher, just delete this file:
~/.mozilla/firefox/<your profile>/search.sqlite
Since version 2 no longer uses the file, I have no idea how it re-vivified or why. It must have a good reason.
Generate a new CA certificate (found here):
openssl req -new -x509 -extensions v3_ca \
-keyout private/cakey.pem \
-out cacert.pem -days 3650 \
-config ./openssl.cnf
Then distribute:
openssl x509 -in demoCA/cacert.pem \
-outform DER -out cacert.der
and put der file on a web site for download.
For old expired certs (lazy SysAdmin), find certificate index in demoCA/index.txt:
V 150226202501Z 01 unknown [blah]
then revoke that certificate:
openssl ca -revoke demoCA/newcerts/01.pem
then issue a request (differs for IE/Apache, etc.) and process it:
openssl ca -policy policy_anything \
-out exchange.americasmart.com.cer \
-infiles certreq.txt
I’ve run into this problem many times when I travel and the hotel I’m staying at intercepts all SMTP traffic and runs it through their own mail server. I run Exim on my laptop, and it forwards all outbound emails (from me) to my Exim server at mail.rasey.net. Since SMTP isn’t secure and I can never be sure what IP address I’ll be connecting from, I do both authentication and encryption on that connection. And that’s where the hotel problem occurs: no hotel mail server would be able to authenticate me and encrypt my connection, nor would I want it to.
As a workaround, I usually just disable authentication and encryption during my stay. Not that I was happy doing it, but I don’t travel that often, so it wasn’t a huge deal.
Recently, though, BellSouth decided that there is no reason for their home DSL customers to use port 25. And without warning, my mail setup was broken. So what to do?
Since this has been simmering on the back burner of my mind for awhile, I knew the easiest and most elegant solution was to build an SSH tunnel from my laptop to my mail server. This solution is small, fast and free; a Linux user’s dream. It has the added bonus of encrypting everything passing through the tunnel, so I’m doubly encrypted.
Here’s how it works. All you need is SSH access somewhere outside your network and an SSH client. If you’re a windows user, you can translate all I’m about to say and apply it to PuTTY, a free SSH client that runs on windows.
Normally, an SMTP session is pretty simple. A client connects to an SMTP server on port 25, issues some commands, sends some data, then disconnects. With a tunnel, the client connects to itself on a throwaway port. SSH transparently intercepts the connection, sets up an encrypted session with the SSH server, and any command or data that comes through that tunnel is forwarded to the SSH server’s SMTP port. Easy!
What if the SSH server isn’t running a mail server? Just tell your SSH client the final destination, and if the SSH server can send mail, that’s all that needs to happen.
The command to run on the client using openssh is:
ssh -f -N -L 1234:localhost:25 ssh-server
Where:
- -f forks ssh into the background
- -N tells ssh that no command will follow (try it without it)
- -L 1234:localhost:25 sets up the tunnel
- 1234 is the throwaway port on your client (anything under 1024 and you’ll have to be root to establish the tunnel… but why bother?)
- localhost:25 is port 25 on the server side. It is localhost because the SSH tunnel terminates on the server side, and when the little packets emerge from the end of the tunnel, they are going to… localhost!
- ssh-server is the destination SSH server. If you don’t want to have to enter a password whenever you build the tunnel, look at using ssh with authentication keys instead of a password. If you don’t know what that means and are still typing a password every time you use ssh, go buy Linux Server Hacks and start living.
Once you’ve set up the tunnel, try it out:
telnet localhost 1234
You should be connected to your far-end mail server! Now all you have to do is tell your mail client or MTA on the client to connect to localhost:1234 instead of mailserver:25. The applicable sections using Exim are your transport:
remote_smtp: driver = smtp port = 2001
… and your router:
send_to_smart_host: driver = manualroute route_list = !+local_domains localhost self = send transport = remote_smtp
The self = send part is necessary to keep Exim from complaining about your mail going from localhost to localhost. It obviously doesn’t know about the tunnel.
The only problem I’ve had with this setup is that it will time out after a period. I’ve tried all kinds of solutions that I’ve found on the internet, but they all timed out eventually. I ended up writing a little perl that can run in the background and make sure the tunnel stays up. It just connects on the magic port, says ‘quit’, waits 60 seconds and repeats. It looks like this:
#!/usr/bin/perl use strict; use warnings; use Net::Telnet; while (1) { my $telnet = new Net::Telnet( Host => ‘localhost’, Port => 1234, Timeout => 2, Prompt => ‘//’); $telnet->waitfor(’/.*$/’); $telnet->print(’quit’); $telnet->close; sleep 60; }
Just build the tunnel then background the script. Happy emailing when they don’t want you to!