Meteor add has broken this morning

Hello everybody.

Friday I was happily developing my next killer app. This morning meteor add stopped working.

mamluk@Thinkpad-X1:~/Projects$ meteor create test
test: created.

To run your new app:
cd test
mamluk@Thinkpad-X1:~/Projects$ cd test/
mamluk@Thinkpad-X1:~/Projects/test$ ls
test.css test.html test.js
mamluk@Thinkpad-X1:~/Projects/test$ meteor add fortawesome:fontawesome


I’m using ubuntu 15.04, but I tried it also in the cloud, with ubuntu 14.04. Anyone else experiencing this? Is it me or meteor add broke this morning?

Works for me both on Windows and Ubuntu.

1 Like

Ok it works now.

My timezone is UTC+1

This morning @ 10:12 my automatic deployment tool reported some errors on my machine. Errors which were not present on Friday.

At 10:48 I concluded that nothing was wrong with my Ubuntu or routing, and I started testing on our cloud, both in Europe and US. It was not working.

At 11:18 I posted here.

At 11:25 I bought a VPS. I was waiting for activation when things got back to normal.

Anyone else ever experienced this? It’s not the first time for me, but for the first time I have been able to document and replicate it. What could have happened?

Wow, aparently I’m not alone with this.
I’m experiencing the same (or at least something very similar) right now.

Just created a topic for it:

1 Like

The same for me!

1 Like

so it seems like a widespread issue. It seems like it’s not a local problem, but a problem with meteor servers.

Anyone from MDG cares to comment? How can we help you?

1 Like

So this is what I wonder;

  • Given that meteor’s package servers are offline
  • If the project is not a new one,
  • but one with previously added packages, (therefore seeking package updates),
  • even though there is no need for an update,
  • one won’t even be able start the app
  • therefore not be able to work.
  • thousands of developers losing thousands of hours of work time

Is this what we are looking at, or am I jumping to conclusions?

1 Like

Hm, interesting.
I’m definitely losing some good work hours over here.

But for other devs (e.g. @dandv) it seems to work?
How is that possible then?

@nilsdannemann is it not working for you yet?

I wouldn’t over exaggerate this:

  1. Meteor is not mission critical yet. We all know this.

  2. A forum search didn’t reveal similar issues in the past, so it’s not widespread yet.

  3. The solution is to be able to mirror atmosphere and meteor servers. I’m willing to host a free public mirror. Can MDG help us by providing us the software needed to run a clone?

Hey @muaddib,
things are working now. Sweet.

If atmosphere (package server) being offline breaks development workflow (which we should get confirmed before jumping to a conclusion) then I think this is very well mission critical.

Meteor is 1.0, and some very serious apps are using it for multi million dollar businesses, and Meteor itself is providing paid support subscriptions, therefore, yeah, meteor definitely is mission critical. At least for quite a number of us.

Also, I know for a fact that there has been availability issues with both atmosphere and the package server in the past. You can search the old forums for that.

I agree that Meteor should provide means to mitigate such issues, I really like and appreciate your idea (and offer to chip in) of mirror servers. That has proven itself quite successful with other package ecosystems like ubuntu’s.

But I guess it is not a very trivial task to tackle. You need to bake that support into the meteor tool. Also, you need to make sure packages on the mirrors are both up to date and that they are authentic. There’s a huge potential for a security issue there and it needs to be addressed very carefully.

But, if MDG opts in to support mirrors, that also means that there will very likely be support for private package servers as well (basically the same idea) and that I would applaud on foot :smile:


BTW, I think there is a more general issue and Amazon is to blame:

1 Like

what I meant by “not mission critical” is that it is stable, but not to the point where it never fails.

Mirrors and private repos are a step in that direction.

1 Like

Right now, package security suffers from the tacit assumption that the code we see on GitHub for a package, is the code we get when we meteor add it. But that might not be the case. An attacker can publish a useful package on GitHub, then after getting enough users, they can meteor publish on MDG’s servers a version with malicious code added. Auditing done against the code published on GitHub will never catch the malicious code.

I hope those serious about security look at the code added by meteor add, but this potential discrepancy is a little disturbing and could be solved on Atmosphere with a badge indicating that the code in the GitHub repo for a package mismatches the code on MDG’s package server.


In fact, apart from those package authors for whom I’ve built some degree of trust, I don’t meteor add packages, but instead clone it to a local package directory, and use it from there, sometimes even take out the pieces of code that I need for a project, make it a local part of the project itself and discard the package all together.

But, then again, package security has been a long standing argument both over at the old forums and here. I’m guessing there still is huge ground to cover.